[ On Monday, July 8, 2002 at 04:44:45 (-0700), Paul Goyette wrote: ]
> Subject: Programming question - signal handlers
>
> OK, maybe this isn't quite the correct list, but it's the best I can
> think of!
> 
> There's this program I've been working on, and I'm having some
> difficulties dealing with signal handlers.  The program explicitly
> catches and handles SIGSEGV and takes some clean-up action so that
> some datafiles don't get left corrupted.

Assuming that your cleanup will be successful is a _bad_ idea,
especially if what you're doing is writing out data in some attempt to
make your files internally consistent.  The SIGSEGV could have happened
anywhere, including in some code manipulating the data you're about to
write out.  The safest thing to do is nothing -- just let the system
dump your program's core image, i.e. don't catch SIGSEGV.  You'll have
to do some consistency checking on your files before you use them again
anyway, regardless of whether your program thinks it might have been
able to save anything.

>  But it the process, the
> "normal" action of dropping a .core file doesn't happen, so I'm left
> without a clue as to where the SEGV occurred.
> 
> So, is there any was I can make the program do BOTH the default
> sigaction AND the specified handler?

not likely....

>  Or, alternatively, is there a
> routine I can call from within the program's handler that will drop
> a core file suitable for use in gdb?

the most generic solution is to call abort(3) -- I don't think sending
another SIGSEGV from within the handler is a good idea, and it may not
even work at all with POSIX signals.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>