httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: cvs commit: apache-2.0/src/lib/apr/lib apr_execve.c apr_pools.c apr_tables.c
Date Wed, 24 Nov 1999 08:03:15 GMT
On Tue, 23 Nov 1999, Ryan Bloom wrote:
> On Tue, 23 Nov 1999, Greg Stein wrote:
> > On 23 Nov 1999 wrote:
> > >...
> > >   --- apr_execve.c	1999/11/22 18:01:14	1.4
> > >   +++ apr_execve.c	1999/11/23 21:22:45	1.5
> > >   @@ -349,7 +349,6 @@
> > >    	    newargv = (char **) malloc((p - lbuf + 1)
> > >                          + (i + sargc + 1) * sizeof(*newargv));
> > >    	    if (newargv == NULL) {
> > >   -		fprintf(stderr, "Ouch!  Out of memory in hashbang()!\n");
> > >    		return NULL;
> > 
> > Do callers check this return code? Should we have an abort() here?
> libraries shouldn't be killing off processes because there is a problem,
> they should alert the program that there is a problem.  If we aren't
> checking the return code, we should be.  That will be fixed in the next
> few patches.

That's a cop-out. We are talking Apache here. All throughout Apache, we
allocate memory with the presumption that if the function returns, then we
*have* allocated that memory.

You simply CANNOT change those semantics right now.

In other words: we *are* going to abort(). And it is very incorrect to
abort without even attempting to state what happened.

[ caveat: if you want to check stuff *withing* APR, then okay. but APIs
  exposed to Apache *never* return an "out of memory" error. ]

> > I still think we need a platform-dependent way to log this kind of error
> > message. Apache should NOT simply exit without saying anything. The admin
> > could be scratching their head for weeks until they figure out "oh! maybe
> > it is running out of memory!"
> > 
> > -0 on abort() with no message.
> There is no good way to write an error message in a platform independant
> way.  I am removing the exit calls over time, but the fprintf's go away
> now, because they don't work on all systems.

Yes there is. There is a very good way, and I outlined it previously.
I'll state it one more time:

On Windows: put the message into the Event Log.
On Unix: write it to stderr.

In fact, these are the "right ways" to do this for each platform. We can
use it. If we run into that stupid NT vs Win9x in that no event log
exists, then write it to a damn text file in "C:\ApacheErrors.txt". When
APR is loaded, then open the Event Log or output file (so you won't have
to allocate any resources when it comes time to use them). Within APR (or
Apache itself for that matter), you can then just call something like
ap_abort_with_msg("whatever"). It will ensure the message is written to
the platform-specific place and abort().

This is APR... we can use platform-specific mechanisms to log these

Really: we can't just abort() without telling the user what happened. I've
been bitten by that several times in the past and it was a pain in the
ass. And hell... I'm a programmer with debug tools available! I hate to
think what would happen to Joe Sysadmin.


Greg Stein,

View raw message