Re: error checking out codes

[Greg A. Woods]

[ On Thursday, January 3, 2002 at 11:11:44 (-0500), Larry Jones wrote: ]
> Subject: Re: error checking out codes
>
> Signal 11 is SIGSEGV (segmentation violation), which usually means
> you're running out of (virtual) memory.

Ah, no, SIGSEGV means your program tried to access a storage area that
was not within its allocated process space.  I.e. there's a wild pointer
or array reference, NULL de-reference, buffer overflow, etc. somewhere.
This is almost certainly an indication of a VERY serious programming
bug.  SIGSEGV should NEVER happen in a correctly functioning program, no
matter how much memory it has allocated or whether the system has denied
any further allocation attempt(s).

(perhaps you're thinking of stupid brain-dead storage allocators like
the one that is/was in the original Unix Bourne Shell which blindly
assume that a SIGSEGV is an attempt by the allocator to grow the
process' storage heap area)

>  CVS should detect that and
> handle it more gracefully, but some systems make that impossible to do.

NO WAY!  No program should ever try to gracefully handle SIGSEGV (or
SIGBUS, or other signals which are indications of programming bugs)!

A core dump is the best result.  Once a SIGSEGV (or SIGBUS, etc.) has
been triggered there's no way to know if it's safe for a signal handler
catching them to try to do anything to clean up and often more damage
can be done inadvertently.  The program's internal state, variables,
allocated storage, etc., is in an undefined state and anything or
everything could be corrupted.  Let the user clean up any mess that
might be left behind (eg. lock files, half-written temporary files,
etc.).

Only with SIGABRT (SIGIOT), which is normally triggered by the program
itself with assert(), is it relatively safe to try to clean up, though
even then you are, by definition, dealing with an undefined internal
state so you have to be VERY careful to only do the bare minimum and
then of course to reset the SIGABRT handler to allow a core dump and
trigger it again since the whole idea of assert() is to get a core dump
that can be debugged post-mortem.

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>