You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@ibm.net> on 2000/02/28 04:59:10 UTC
2.0 on UNIX gets SIGSEGV if no SysV semaphores avail
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.
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).
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).
. 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.
. and most importantly, why did I run out of semaphores?
(later; this code has to work reasonably regardless)
--- src/lib/apr/lib/apr_pools.c.old Thu Jan 27 23:21:55 2000
+++ src/lib/apr/lib/apr_pools.c Sun Feb 27 23:22:41 2000
@@ -558,16 +558,25 @@
ap_pool_t *ap_init_alloc(void)
{
+ ap_status_t stat;
#ifdef POOL_DEBUG
char s;
known_stack_point = &s;
stack_var_init(&s);
#endif
- ap_create_lock(&alloc_mutex, APR_MUTEX, APR_INTRAPROCESS,
- NULL, NULL);
- ap_create_lock(&spawn_mutex, APR_MUTEX, APR_INTRAPROCESS,
- NULL, NULL);
+ stat = ap_create_lock(&alloc_mutex, APR_MUTEX, APR_INTRAPROCESS,
+ NULL, NULL);
+ if (stat) {
+ fputs("ap_create_lock() failed\n", stderr);
+ exit(1);
+ }
+ stat = ap_create_lock(&spawn_mutex, APR_MUTEX, APR_INTRAPROCESS,
+ NULL, NULL);
+ if (stat) {
+ fputs("ap_create_lock() failed\n", stderr);
+ exit(1);
+ }
permanent_pool = ap_make_sub_pool(NULL, NULL);
#ifdef ALLOC_STATS
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: 2.0 on UNIX gets SIGSEGV if no SysV semaphores avail
Posted by David Reid <dr...@jetnet.co.uk>.
Wasn't this a discussion a few times before?
APR should be returning proper error codes and Apache deal with them. If it
isn't we need to fix it (as we've done already in a number of places).
:)
----- Original Message -----
From: "Greg Stein" <gs...@lyra.org>
To: <ne...@apache.org>
Sent: Tuesday, February 29, 2000 12:11 AM
Subject: Re: 2.0 on UNIX gets SIGSEGV if no SysV semaphores avail
> On Mon, 28 Feb 2000 rbb@apache.org wrote:
> >...
> > > . 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.
>
> Didn't we get a callback in there? In other words, does APR still die, or
> just Apache (via the callback) die?
>
> I would also tend to agree with Ryan: if APR has sufficient/proper return
> codes, then it shouldn't ever need to log. The caller should do the
> logging when it is returned an error.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>
Re: 2.0 on UNIX gets SIGSEGV if no SysV semaphores avail
Posted by rb...@apache.org.
>
> Didn't we get a callback in there? In other words, does APR still die, or
> just Apache (via the callback) die?
I guess if you want to get technical, Apache is the one dying. I figured
we are in the APR layer, even if we are calling back to Apache. :-)
Ryan
>
> I would also tend to agree with Ryan: if APR has sufficient/proper return
> codes, then it shouldn't ever need to log. The caller should do the
> logging when it is returned an error.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>
Come to the first official Apache Software Foundation
Conference!!! <http://ApacheCon.Com/>
_______________________________________________________________________________
Ryan Bloom rbb@ntrnet.net
2121 Stonehenge Dr. Apt #3
Raleigh, NC 27615 Ryan Bloom -- thinker, adventurer, artist,
writer, but mostly, friend.
-------------------------------------------------------------------------------
Re: 2.0 on UNIX gets SIGSEGV if no SysV semaphores avail
Posted by Greg Stein <gs...@lyra.org>.
On Mon, 28 Feb 2000 rbb@apache.org wrote:
>...
> > . 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.
Didn't we get a callback in there? In other words, does APR still die, or
just Apache (via the callback) die?
I would also tend to agree with Ryan: if APR has sufficient/proper return
codes, then it shouldn't ever need to log. The caller should do the
logging when it is returned an error.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: 2.0 on UNIX gets SIGSEGV if no SysV semaphores avail
Posted by rb...@apache.org.
> 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.
-------------------------------------------------------------------------------