patch: break into debugger on death in sanitizers

Kostya Serebryany kcc at google.com
Fri Oct 25 21:39:51 PDT 2013


On Fri, Oct 25, 2013 at 10:54 PM, Chandler Carruth <chandlerc at google.com>wrote:

>
> On Fri, Oct 25, 2013 at 11:52 AM, Kostya Serebryany <kcc at google.com>wrote:
>
>> I am not opposed to this change, but I'd like to test it a bit more
>> carefully to make sure none of our users get angry on us for behavior
>> change.
>> I'd suggest to put this sigtrap under a flag (off by default) and then
>> flip the default to true after a bit of testing.
>> We already have abort_on_error, may add sigtrap_on_error or some such.
>>
>
> Ugh.
>
> So, I'm kind of sad about this because this is the number one most
> frustrating part of debugging UBSan and ASan failures -- they completely
> misbehave when running under gdb. =[
>

I've analyzed 1000+ asan reports and never needed to debug asan reports in
gdb (aside from cases when it was an asan bug).
I'd like to understand more why users need that.
For ubsan the solution is to print stack traces (Alexey and Richard
discussed this already, afaik, and have a plan).
Some users did want gdb and so there is an easy solution: in gdb you can
put a breakpoint on __asan_* (__ubsan*) function:
https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#gdb

Making *san trap on error will make gdb experience even better, but I do
want to make sure it doesn't hurt other use cases.

--kcc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131026/18c129d7/attachment.html>


More information about the cfe-commits mailing list