> > The real issue, however, is how you can arrange to avoid segfaulting
> > again in fairly short order - after all the fact that you ran of the
> I don't need to be sure to have a trustable environment after the core dump
> because in the catch signal function I exec() another process that will take
> place of the faulty one. This is what I already do but I would like to analyze
> the core (if I find a way to dump it) later to track the bug(s) on the dead
> processes. If anybody have an idea I will be glad to test it! ;-))
Ok you're planning to do "the right thing" - here's how to do what you
want (assuming posix signal semantics)
Set up a handler for SIGILL, SIGSGEV etc
in the handler
1) reset the handler to the default action
2) fork
3) in the parent, chdir to somewhere to leave the core file then
re-send the signal to yourself with kill and exit the handler
4) in the child exec a new copy
This should get you a core dump with the program counter pointing at
the point the original segv or whatever occurred - it doesn't really
matter if you swap what you do in the parent and child (i.e. the
parent could do the exec if you want).
Remember that setuid programs don't leave core files.
Quote:> /-----------------------------*-----------------------------\
> | Systmes & Technologies | Tl: +33 2 96438787 |
> | Informatiques du Ponant | Fax: +33 2 96438788 |
> | 27, rue Auguste Brizeux | web: http://www.stip.fr |
> | 22200 Guingamp - France | Minitel: 3615 STIP |
> \-----------------------------*-----------------------------/
Nice place Guingamp, as I recall, but I never could get the hang of the
pronunciation :-(