This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: collecting data from a coring process
- From: Paul Marquess <Paul dot Marquess at owmobility dot com>
- To: Samuel Bronson <naesten at gmail dot com>
- Cc: Dmitry Samersoff <dms at samersoff dot net>, vijay nag <vijunag at gmail dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Tue, 6 Sep 2016 16:40:57 +0000
- Subject: RE: collecting data from a coring process
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Paul dot Marquess at owmobility dot com;
- References: <CY1PR0501MB11783F479AF7D639A82FE02F95EC0@CY1PR0501MB1178.namprd05.prod.outlook.com> <CAKhyrx_9GnLTBDKkhW_y4QG+f3xV_SL-Vtg0WN+vU6UXnY-qLA@mail.gmail.com> <CY1PR0501MB1178A955FBE2AAAE65655EAB95EC0@CY1PR0501MB1178.namprd05.prod.outlook.com> <87b59611-f5d1-628d-fd41-85ce6c6eb50b@samersoff.net> <CY1PR0501MB117800AACB41115C303EB9D495E60@CY1PR0501MB1178.namprd05.prod.outlook.com> <CAJYzjmefda8F9zLbr0FNXChogLMLF2TMHZATFCK+tiAirG1ahg@mail.gmail.com> <CY1PR0501MB117886690FFE9F9EE007155095E60@CY1PR0501MB1178.namprd05.prod.outlook.com> <CAJYzjmf0a2Dd8XbOQaO3937Bcab1AW9gVp=r3mKSgUq_27G8ow@mail.gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
From: Samuel Bronson [mailto:naesten@gmail.com]
> 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!" :-).
I agree that "async-signal-safe " is something that needs to be considered, but it isn't the only thing. I've seen plenty of cores where corruption of a data structure inside malloc itself was the trigger for the SEGV. That's why I need to be sure that any code executed in the signal handler isn't going to blow up.
I've had success with a toy setup that checks if the following scenario will work.
I have a Parent process that spawns a Child process. The child process contains a deliberate SEGV error.
In the Child process I get the signal handler to send USR1 to the parent process, then send SIGSTOP to itself. Once the SIGSTOP is released I get the process to exit.
The Parent process has a handler to catch the USR1 signal. I use this to trigger the execution of gdb. When I get gdb triggered it seems to be working fine -- stack is still present & I can access data structures. Exiting gdb must send a CONT to the process because it the child process then exits normally.
Still early days, but I like this approach because it means I only need to add a small amount of code in the signal handler of the coring process.
Paul