This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: collecting data from a coring process

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]