I realize that some Address Sanitizer capabilities may vary from GCC to clang ; my interest here is primarily with GCC (currently using GCC 6.2 and 7.3)
I can use ASAN_OPTIONS to set halt_on_error=0 to keep going after a defect is reported, or set it to 1 to stop as soon as the first defect is reported.
What I am looking for, is a way to stop after N defects. halt_on_error=N doesn't work, because it's simply a binary setting (on/off).
Is there any other way to achieve this:
When simply running the exe at the command line, via some env setting ?
When inside the debugger - e.g. something like b some_asan_defect_reporting_function if (asan_defect_count == N)
Thanks in advance for any info on the above.
Gordon
There used to be a supplementary ASAN_OPTIONS=max_errors=N flag for halt_on_error but it raised too many questions during code review and didn't have compelling use-cases so I abandoned it half-way (you can see it was dropped at this stage). If you feel it might be useful, try filing a bug in Sanitizers tracker.
Related
I stumbled upon an issue when I recently switched to VSCode as editor.
I have several projects that have a full (medium-complex+) autotool
setup and they all work fine. However I discovered that the makefile plugin for VSCode in order to initialize itself (and finding all dependencies and targets) starts by running
make --dry-run --always-make
as first time initialization. This throws the makefile (or actually the
re-config) into an endless loop re-running "configure" (since the targets are never resolved to disk).
I have also confirmed this behavior with the smallest possible autoconf/automake
setup. I can also kind-of understand why this happens (and it seems make
have an internal way to discover this exact situation with the special
variable MAKE_RESTARTS that could possible be used to detect a cyclic
behavior)
Is there a known best-practice workaround ? or is it even a reasonable expectations that these two options in combination should work? (Good to have a second opinion before I go down the rabbit-hole of reminding myself of all the details I forgot about the magical land of autotools)?
I tried to use AFP (02/22/2021) with Isabelle 2021, but the jEdit/Isabelle PIDE wouldn't load after the AFP directory is added to the user ROOT file. The is shown below and seems to be about a specific package:
I don't really need the entry in question (, or know what it does).
My question is:
Is there a way to use a subset of AFPs and exclude problematic entries in the screenshot?
-- Update ---
As pointed out in the comments, the AFP seemed to be lagging a couple of days behind. Using afp-02-24-2021, the initial error went away. However, when selecting a session Jordan-Normal-Form from jEdit, there is a new error about JNF-AFP-Lib build failing, as shown below:
The question remains. The AFP seems to be a large collection and there could be multiple sources of error.
In case of such errors, is there a way to select a subset of AFPs to use or debug?
If not, is there a systematic way to test which afps do or do not build?
Original question
The problem was because you (unknowingly) used an AFP release that did not match the Isabelle release. To avoid that problem in the future, I recommend using the Mercurial repository directly:
https://foss.heptapod.net/isa-afp/afp-2021
The Mercurial repository for a new Isabelle release gets created during the RC phase, so you can always be sure to have matching versions.
In the case of these mismatches, it is usually not possible to select a subset of the AFP that "works", because between 2020 and 2021, the session management has changed considerably.
Update
The problem you're facing here is that you have selected a big session as a prerequisite and it takes too long to build with the default configuration.
You can build the session on the command line with an increased timeout as follows:
isabelle build -bv -d <path to afp>/thys -o timeout_scale=3 Jordan_Normal_Form
Increase the factor if it keeps timeouting.
General remark
You ask, "In case of such errors, is there a way to select a subset of AFPs to use or debug?". The answer to that question depends on the kind of error. Your post currently contains two vastly different problems, so it's not possible to give a general answer, unfortunately.
My package introduces registry entries. Changes by site administrator should not be overwritten on reinstall of the package.
Many ways to Rome. I chose ftw.upgrade. I like the declarative way of the upgrade step syntax. Its possible to use an upgrade directory for generic setup xml-Files like propertiestool.xml. No need to define handler python code. The upgrade works well. The admin can upgrade from control panel and in my case the new property is added. Insomma: For a new property just these have to be added: an upgrade-step declaration for source and destination version and directory where to find the properties.xml. Thumb up! –
You can pilot what to do when installing a Plone add-on by providing an Extension/install.py file with a install method inside:
def install(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-your.pfile:default')
This way you are driving what Plone should do when installing.
If you need it: the same if for uninstall:
def uninstall(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-example.gs:uninstall')
This way you can prevent the uninstall step to be run when reinstalling.
Warning: as Mathias suggested using quickinstaller -> reinstall feature is bad.
Warning: this will not probably work anymore on Plone 5 (there's open discussion about this).
I think what you describe is one of the problems upcoming with the increasing complexity of Plone's stack, and one of the reasons, why it is not recommended to execute a re-install anymore, but to provide a profile for each version of the Add-On, via upgrade-steps (as Mathias mentioned). That increases dev-time significantly and results in even more conflicts, of my experience. Here are the refering docs:
http://docs.plone.org/develop/addons/components/genericsetup.html#add-upgrade-step
Elizabeth Leddy once wrote an Add-On to ease that pain and I can confirm it does:
https://github.com/ampsport/amp.ezupgrade
And the great guys from FTW, too, I never used it, but looks promising:
https://pypi.python.org/pypi/ftw.upgrade
Neither used this one, even claims to have some extra goodies, like cleanup broken OFS objects and R. Patterson's on it:
https://github.com/collective/collective.upgrade
As we're here, the first good doc I could find about it ~ 1.5 years ago, comes from Uwosh, of course:
http://www.uwosh.edu/ploneprojects/docs/how-tos/how-to-use-generic-setup-upgrade-steps
Another solution can be, to check, if it's an initial- or re-install, and set the properties programatically via a Python-script, conveniently called 'setuphandlers.py', like described in this answer:
How to check, if my product is already installed, when installing it?
That way one can still trigger re-installs without blowing it all up.
Lastly, a lot of the GS-xml-files understand the purge-property, setting it to False, will not overwrite the whole file, just your given props. This might, or not, apply to your case, you can find samples in the above referenced official doc.
I was reading about system calls and encountered system calls in the form open(2) , read(2),write(2) and others. I am trying to find whats 2 in the paranthesis. First I thought its the flag settings but its not the flags i found out. Please help me understand this. Please bear with me if the question is too silly.
Thanks
The “2” refers to the section of the Unix manual. Section 2 is for system calls. Section 3 is for library calls. The distinction has become somewhat arbitrary for certain calls, which used to be system calls (essentially direct calls to the kernel) but are now (at least on some versions of Unix) library functions that do significant work before calling the kernel.
Check out the Wikipedia page about “man pages” for more.
I think that may just be referring to the section of the man pages it is in. Like man 2 read for example.
It indicates the section in the man page
http://en.wikipedia.org/wiki/Man_page#Manual_sections
As you can see there, 2 is listed as system calls, what you'd expect since open, read and write are pretty much system calls :)
This is useful, for example if you want to look for perl's open, you can do:
man open -S 3 # -S switch here is to specify which section in man page
Which, if any, R IDEs (e.g. StatET, Revolution R, RStudio, ESS, NppToR, others) support conditional breakpoints?
This is available via bp in the debug package, or via an additional bit of code that invokes browser() based on a condition. However, it can be more efficient to be able to toggle a particular line # and quickly enter a conditional breakpoint for that particular line, without having additional code or console activities.
Note 1. I've searched a bit for these, and it seems that conditional breakpoints are not available in RStudio, and I think the same may be true for StatET. There appears to be support in ESS (see this page), though I'm not yet familiar with ess-tracebug and whether it's easy to use. It also seems that this works only for older versions of ESS; I'm not yet familiar with functionality for more recent versions.
Update 1. I'm selecting an answer (the only one - Andrie's). The question was answerable regarding whether any IDE supports conditional breakpoints, and, fortunately, Andrie has demonstrated that there exists a solution. I remain interested in any other IDEs that support this, though Eclipse is good enough for now. (At the moment, I prefer Rstudio, but this is already in their feature request list.) If anyone has expertise in ESS and can demonstrate that functionality, I'm sure it will benefit others who happen upon this question.
Yes, this is possible with Eclipse + StatET 2.0 in R 2.14-1.
Eclipse supports conditional debugging, and StatET 2.0 supports visual debugging (as long as you have a fairly recent version of R.)
Assuming you know your way around Eclipse, do the following:
Start a debugging session in Eclipse (i.e. invoke a Debug configuration, not a Run configuration)
Set a breakpoint in your code
Open a Debug perspective
Run your code
With the debug perspective open, you will have a pane that contains tabs for Variables / Breakpoints. In the breakpoints tab, select your breakpoint, then click the Conditional / Expression tickbox and enter your condition.
In searching for this answer, I found the following pages helpful:
Download and install StatET
How to start a debugging session in StatET
How to set a conditional breakpoint in Eclipse
There is a little trick to set a conditional breakpoint in rstudio:
for(i in 1:10){
if(i==5){
print("set the breakpoint at this line by shift+f9")
}
i*i
}
The only drawback is you need to add some extra code
The preview release of RStudio v0.98 has this feature:
http://www.rstudio.com/ide/docs/debugging/overview
Only drawback is your function should be in the same file with your main code if you want to set a breakpoint in your function.