Re: collecting data from a coring process

[David Niklas <doark at mail dot com>]

On Fri, 26 Aug 2016 12:33:24 <Paul.Marquess@owmobility.com> wrote:
> > On Fri, Aug 26, 2016 at 2:36 PM, Paul Marquess
> > <Paul.Marquess@owmobility.com> wrote:  
> > > I have an existing Linux application that uses gdb to collect data
> > > from a process if it cores. Currently I've been doing that with gdb
> > > after the core is written to disk. No problem there.
> > >
> > > The requirements have now changed and it won't be possible to allow
> > > the core file to be written to disk. That means I need a way to
> > > (somehow) get gdb to collect the data while the process is still in
> > > memory.
> > >
> > > My first thought was to add a script
> > > in /proc/sys/kernel/core_pattern to catch the process as it is
> > > coring. Then I get gdb to attach to the PID of the process that is
> > > about to core. Unfortunately, when I tried that, gdb gives me this
> > > error
> > >
> > >     Unable to attach: program terminated with signal SIGSEGV,
> > > Segmentation fault. No stack.
> > >
> > > That seems to imply that by the time /proc/sys/kernel/core_pattern
> > > kicks in it is too late to use the PID with gdb.
> > >
> > > Anyone know of a way to do this? Preferably one that doesn't
> > > involve changing the process itself.
> > >
> > > cheers
> > > Paul  
> > You can do one of the following
> > 
> > 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. Just taking pointes as an example, once in the
> signal handler I'm in a situation where I can't trust that any pointer
> contains a valid value. A quick search suggests I can guard against
> that by using a signal handler. But I'm already in one! If there is
> some prior art that shows how to safely dump data from a process once a
> SEGV has been triggered it would make my day.
> <snip>

Oh, oh, I know how to do this (finally a chance to be of use on
gdb's mailing list :) Ok, assuming that you know what variables you can
access or that you can stick them in a struct what you do is enter the
signal handler (hear after known as SH), printing the values one by one. 
When one of the values causes a SEGV then you reenter SH which checks an
atomic type to see if your in SH and if so then another atomic type to
see if you've begun to print the values.
If so then a new branch is executed and what gets printed is an
inaccessible error value.
Control returns to the first SH and it continues iterating.

WARNING: There may be better ways to do what you want, like dump core to a
tmpfs (which is in memory anyway so it leaves no trace on disk).

Sincerely,
David