On OS X, when running GUI apps, there is no console output at all, and that means that you will just not see the ASan report, and it will not be stored anywhere. Embedding the report into the crashlogs sounds look like a good idea, but having abort_on_error=1 is a prerequisite for that. Also the behavior makes more sense even if the report is not contained in the crashlog, because you at least get a current stacktrace containing "__asan_report_error" and pointing to the invalid memory access. Without that, the GUI program just quits and you get no indication of what happened.
Kuba On Fri Jan 16 2015 at 9:18:48 PM Konstantin Serebryany < > [email protected] <javascript:>> wrote: > >> On Fri, Jan 16, 2015 at 12:42 AM, 'Alexander Potapenko' via >> address-sanitizer <[email protected] <javascript:>> wrote: >> >>> On Fri, Jan 16, 2015 at 6:57 AM, Kuba Brecka <[email protected] >>> <javascript:>> wrote: >>> > Hi everyone, >>> > >>> > I'd like to propose turning on the ASan runtime flag "abort_on_error" >>> by >>> > default on OS X. The main reason for that is crash logs: on OS X, crash >>> > reports are stored for all crashes, but ASan currently makes the >>> program >>> > exit(1) by default, which is not a crash. This can make you completely >>> miss >>> > some ASan report, especially in cases where you don't directly look at >>> the >>> > console output (you're logging into a file or something). >>> Will ASan reports be stored along with the crash reports >>> automatically? If no, can we fix that somehow? >>> >>> > I know there's some downsides of that, for example that crashes >>> generate >>> > core dumps which are huge with ASan - therefore I'm only proposing >>> this for >>> > OS X where we don't generate core dumps by default. Another thing that >>> I'm >>> > aware of is the ASan test suite, which would generate hundreds of >>> crash logs >>> > (that's undesirable) and run much slower, so we would probably need to >>> > disable abort_on_error for it. >>> It's possible to unmap the shadow before generating the core dump, >>> that shouldn't be a huge problem. >>> >> >> We can also implement >> https://code.google.com/p/address-sanitizer/issues/detail?id=345 >> (MADV_DONTDUMP) >> to dump core for everything except shadow memory (and large allocator >> space on 64-bit). >> Not sure if MADV_DONTDUMP is present on OSX. >> >> >>> >>> > Regardless of these, it still seems to me that abort_on_error=1 is a >>> more >>> > logical default value than the current default. Is there a strong >>> reason >>> > against that? >>> I don't see any strong reasons. >>> >> >> Some reasons against it: >> - consistency with other OSes and other sanitizers. >> - change in existing behavior >> - default behavior becomes more heavyweight/slow >> >> Do we want to change the behavior of asan on Linux and of other >> santizers? (I don't) >> > > abort() makes more sense than a non-zero exit for ASan, but changing the > default now can break a lot of integration. > -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
