This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: collecting data from a coring process
On Mon, Sep 5, 2016 at 7:19 PM, Paul Marquess
<Paul.Marquess@owmobility.com> wrote:
> From: Samuel Bronson [mailto:naesten@gmail.com]
>
>> On Mon, Sep 5, 2016 at 7:09 AM, Paul Marquess <Paul.Marquess@owmobility.com> wrote:
>> > From: Dmitry Samersoff [mailto:dms@samersoff.net]
>> >
>> >> Paul,
>> >>
>> >> >> 1) Why not dump the information that you are looking for into a
>> >> >> file in the process signal handler ?
>> >> >
>> >> > Would love to, but I have no idea what state the process is in once
>> >> > the SEGV has been triggered.
>> [...]
>> > I know we've had problems with signal handlers causing problems, thus my preference to find a way to have the signal handler code do as little as possible and get all the data collection handled at arm's length by gdb.
>>
>> You could just spawn (and wait for) your GDB-launching script from the signal handler; then,
>> the process & stack will still be around for GDB. I think this is even legal!
>
> That's one of the approaches I'm thinking of. I need to check if the fork/exec & wait use malloc.
I think it should suffice for them to be "async-signal-safe "? It
looks like signal(7) documents which functions several versions of
POSIX require to be async-signal-safe, and it looks like there are two
versions of exec*() on there as well as fork() and wait(). Which is
basically what I meant by "I think this is even legal!" :-).