Does setting ASAN_OPTIONS=handle_segv=0 work for you? 

Yes, that works. But I don't want to use this option because we won't get ASan traces
then for real crashes (I have a patch in the bugzilla bug to disable the ASan SIGSEGV
handler in our JS engine, but we really don't want to take it if there are better options).

If we wouldn't have crash traces from ASan anymore, then automation for getting crash
information gets really hard with ASan because core dumps are also not an option.

FYI,
https://code.google.com/p/address-sanitizer/issues/detail?id=65

Android has some platform magic that handles SEGV and prints stack trace to logcat.

I read through the bug you linked. The main difference to me seems that in the bug,
we're always talking about real crashes, just that they're handled differently.

In our case, the developers are explicitly expecting SIGSEGV as part of the correct
program execution, it isn't meant to be handled as a crash (the ASM.js SIGSEGV handler
will handle it's own SIGSEGVs and proceed with execution).

I think we can allow signal handler chaining under a flag.
We can make handle_segv accept one of the three string options: "0", "1" and "chain".
0 and 1 are for backwards compatibility, for generality we can also parse "yes" and
"no".

That would be very nice to have and sufficient for us (I can make the flag even default
to "chain" for us in our code, so that would be fine).

I really don't want to get into signal handler chaining business -- that's too complex
to my taste.
Asan's reports on SEGV contain only one bit of useful information - the stack trace.

If the user's SEGV handler can distinguish between good and bad segv, it can 
print an error message with a stack trace for a bad SEGV. 
Alternatively, it can call __asan_report_error from the asan public API 
(include/sanitizer/asan_interface.h). 

Our user SEGV handler is not installed all of the time. It is only installed when ASM.js
is actually used (otherwise it doesn't make sense to have that handler).

Regarding the chaining complexity, I think the complexity would be in the code that
wants to chain, not in ASan, since ASan can always be the last handler in the chain.
It doesn't have to bother with calling other handlers.

Yeah, we may not modify existing runtime options, but add another one - smth. like "allow_user_segv"
(off by default), that would unconditionally call REAL(sigaction) in sigaction interceptor.
If the user turns this flag on, he is responsible for proper handling of "oldact" output
parameter of sigaction and calling ASan segv handler if necessary.

#8: I see. 
#9: sounds reasonable, go for it. Thanks! 

Should be implemented in r180255.

Thanks, we'll test and let you know if it works :)

Adding Project:AddressSanitizer as part of GitHub migration.