RE: collecting data from a coring process

[Paul Marquess <Paul.Marquess@owmobility.com>]

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.

The process I want to get data from is controlled by a parent process. Had thought I could get the parent to spot the SIGABRT and attach to the child, but the stack is gone by the time gdb attaches to the PID of the coring process. Need to play with that a bit more to see if I can find a way for the child to tell the parent to fire up gdb before the stacks are gone.

Paul