RE: collecting data from a coring process

[Paul Marquess <Paul dot Marquess at owmobility dot com>]

From: David Niklas [mailto:doark@mail.com] 
 
...
> > > 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. 

Can do that for a very limited sub-set of the data I'm dumping, but in general there is just too much data to remember that way.

> 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.

Interesting technique for dealing with recursive signals.

Paul
P.S. Sorry for the delay in following up. Had no internet access for about 10 days.