Re: error checking out codes

[Larry Jones]

Greg A. Woods writes:
> 
> [ 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).

You're correct in the general case, but I was addressing the CVS-
specific case.  (CVS is known to not have any VERY serious programming
bugs.  Well, strongly suspected, at least.)  The most common cause of
this problem with CVS is that some system implementors are brain-dead. 
In particular, there are a number of systems where malloc() allocates
address space without ensuring that there is available virtual memory to
back it up.  On such systems, malloc() returns a non-null pointer even
when you're out of memory and trying to actually use that memory results
in a SEGV.  I believe that those implementors should all be taken out
and shot, but there are laws against that sort of thing.

> >  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)!

I meant it should detect and handle being out of memory.  I believe it
does gracefully (well, as gracefully as possible) handle malloc()
returning a null pointer, but it can't be expected to deal with systems
that lie to it.

-Larry Jones

There's a connection here, I just know it. -- Calvin