patch: break into debugger on death in sanitizers

Kostya Serebryany kcc at google.com
Tue Oct 29 13:49:14 PDT 2013


btw, why is the currently existing flag abort_on_error=1 not enough for
gdb?


On Tue, Oct 29, 2013 at 1:26 PM, Reid Kleckner <rnk at google.com> wrote:

> Based on in person discussion, this is not an option, because there are
> users of ptrace that aren't debuggers.  See lsan and heapchecker for
> example.
>
>
> On Sat, Oct 26, 2013 at 3:50 AM, Alexander Potapenko <glider at google.com>wrote:
>
>> It should be easy to detect whether we're running under gdb (e.g. if
>> we're being ptraced; perhaps something needs to be done in the presence of
>> seccomp-bpf)
>> On Oct 25, 2013 10:55 PM, "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.
>>
>> (may not reply until Mon next time)
>>
>>
>> On Fri, Oct 25, 2013 at 7:26 PM, Chandler Carruth <chandlerc at google.com>wrote:
>>
>>> Sigtrap, which seems less likely to cause deep surprise in the presence
>>> of signal handlers.
>>>  On Oct 25, 2013 3:56 AM, "Kostya Serebryany" <kcc at google.com> wrote:
>>>
>>>>  So this will change the default behavior from doing exit(1) to doing
>>>> abort(), right?
>>>>
>>>>
>>>> On Fri, Oct 25, 2013 at 3:16 AM, Nick Lewycky <nlewycky at google.com>wrote:
>>>>
>>>>> Running sanitized code under gdb can be annoying because the program
>>>>> will print out its error then exit, instead of the usual behaviour when we
>>>>> get an abort() of stopping the program there and allowing the user to
>>>>> inspect its stack trace.
>>>>>
>>>>> Add a trap to the exit path in sanitizer_common. Please review!
>>>>>
>>>>> Nick
>>>>>
>>>>> _______________________________________________
>>>>> cfe-commits mailing list
>>>>> cfe-commits at cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-commits mailing list
>>>> cfe-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>>
>>>>
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>> _______________________________________________
>> 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/20131029/e12954c0/attachment.html>


More information about the cfe-commits mailing list