patch: break into debugger on death in sanitizers

Manuel Klimek klimek at google.com
Sat Oct 26 00:21:39 PDT 2013


On Sat, Oct 26, 2013 at 6:39 AM, Kostya Serebryany <kcc at google.com> wrote:

> 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.
>

Imagine you have an asan report in code you're not overly familiar with,
 and you don't have a good code browsing tool. gdb is often the easiest way
to understand why things happened to get into the state they're in (at
least for me), without having to read all the code.


> 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
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131026/5223dc36/attachment.html>


More information about the cfe-commits mailing list