Re: collecting data from a coring process

On Mon, Sep 5, 2016 at 7:19 PM, Paul Marquess
<[email protected]> wrote:
> From: Samuel Bronson [mailto:[email protected]]
>
>> On Mon, Sep 5, 2016 at 7:09 AM, Paul Marquess <[email protected]> wrote:
>> > From: Dmitry Samersoff [mailto:[email protected]]
>> >
>> >> 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!" :-).