httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject Re: 2.0 on UNIX gets SIGSEGV if no SysV semaphores avail
Date Mon, 28 Feb 2000 16:07:09 GMT

> ap_init_alloc() gets a couple of locks and doesn't check the
> returned status.  The "fix" below has been tested on FreeBSD
> 3.4.

That is a bug and needs to be fixed, but I am against this patch for a
variety of reasons, outlined below.  :-)

> 
> Some issues to consider...
> 
> . Can the caller of semget() log an error message?
> 
>   Almost no apr code writes to the apache log; the stuff that
>   does is kind of ugly (inside ifdef APACHE).
> 

APR is not tied to Apache, and therefore does not know about the Apache
log.  There is one place that this rule is broken, inside of ap_palloc and
it's helper functions, because traditionally, these functions have
reported an error and died.  This is what Apache expects, but it is a bad
idea for anybody else.  For any new functions, APR reports an error by
returning an error code.

>   Is the apache error log function expected to move to apr?  
>   The name would suggest it (ap_log_error() but in 
>   src/main/http_log.c).
> 

No, the prefix for the two projects is the same.  This was debated for
several months here, and it was decided to leave them both using ap_.
Again, APR doesn't understand error logs, it is just a set of routines to
make code more portable,  it is up to the calling program to report
errors.

> . Should ap_init_alloc() just return an error to its callers 
>   and not make the decision to die?  There isn't anything
>   for them to do (but write a log message, of course), so
>   why bother them with such details?
> 
> . How to die properly?  I guess it doesn't matter; I see
>   calls to abort() and exit() in apr.
> 

These two go together, APR should never die on it's own.(Yes, this rule is
broken because the Apache functions used to die on their own, but in
general, APR never dies, because we don't know what another program may
want to do.

I'll fix this code later today, and keep up the good work, you are driving
lots of bugs out of APR.  :-)

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@ntrnet.net
2121 Stonehenge Dr. Apt #3
Raleigh, NC 27615		Ryan Bloom -- thinker, adventurer, artist,
				     writer, but mostly, friend.
-------------------------------------------------------------------------------


Mime
View raw message