You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2001/01/01 01:13:41 UTC
cvs commit: httpd-2.0/server config.c
rbb 00/12/31 16:13:41
Modified: server config.c
Log:
When we are starting the server, we have a pool that can be used to open
the error log. Rather than try to log a regular error, log an error with
the pool that we have, so that we can open stderr successfully.
Revision Changes Path
1.90 +2 -2 httpd-2.0/server/config.c
Index: config.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/config.c,v
retrieving revision 1.89
retrieving revision 1.90
diff -u -r1.89 -r1.90
--- config.c 2000/12/17 03:35:39 1.89
+++ config.c 2001/01/01 00:13:41 1.90
@@ -1462,11 +1462,11 @@
errmsg = ap_walk_config(conftree, &parms, s->lookup_defaults);
if (errmsg) {
- ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, NULL,
+ ap_log_perror(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, p,
"Syntax error on line %d of %s:",
parms.err_directive->line_num,
parms.err_directive->filename);
- ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, NULL,
+ ap_log_perror(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, p,
"%s", errmsg);
exit(1);
}
Re: cvs commit: httpd-2.0/server config.c
Posted by rb...@covalent.net.
We don't have a politically correct fix. I thought you wanted to use a
global variable. Go ahead and implement.
Ryan
On 3 Jan 2001, Jeff Trawick wrote:
> yet another case... (what is the politically correct fix?)
>
> #0 apr_palloc (a=0x0, reqsize=64) at apr_pools.c:939
> 939 blok = a->last;
> (gdb) bt
> #0 apr_palloc (a=0x0, reqsize=64) at apr_pools.c:939
> #1 0x809aeb5 in apr_pcalloc (a=0x0, size=64) at apr_pools.c:986
> #2 0x809fb3f in apr_open_stderr (thefile=0xbfbfbaf4, cont=0x0) at
> open.c:257
> #3 0x8076751 in log_error_core (file=0x80ac2d0 "config.c", line=1427,
> level=40, status=0, s=0x0, r=0x0, pool=0x0,
> fmt=0x80ac752 "%s: could not open document config file %s",
> args=0xbfbfdb44 "R...") at log.c:349
> #4 0x8076996 in ap_log_error (file=0x80ac2d0 "config.c", line=1427,
> level=40,
> status=0, s=0x0,
> fmt=0x80ac752 "%s: could not open document config file %s") at
> log.c:466
> #5 0x8075b1a in ap_process_resource_config (s=0x80cce3c,
> fname=0x80ad37b "conf/httpd.conf", conftree=0x80b7ba0,
> p=0x80cc00c,
> ptemp=0x810e00c) at config.c:1427
> #6 0x80760e0 in ap_read_config (process=0x80c903c, ptemp=0x810e00c,
> confname=0x80ad37b "conf/httpd.conf", conftree=0x80b7ba0) at
> config.c:1685
> #7 0x8077454 in main (argc=1, argv=0xbfbfdc88) at main.c:383
> #8 0x8058411 in _start ()
> (gdb)
>
> --
> Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server config.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
yet another case... (what is the politically correct fix?)
#0 apr_palloc (a=0x0, reqsize=64) at apr_pools.c:939
939 blok = a->last;
(gdb) bt
#0 apr_palloc (a=0x0, reqsize=64) at apr_pools.c:939
#1 0x809aeb5 in apr_pcalloc (a=0x0, size=64) at apr_pools.c:986
#2 0x809fb3f in apr_open_stderr (thefile=0xbfbfbaf4, cont=0x0) at
open.c:257
#3 0x8076751 in log_error_core (file=0x80ac2d0 "config.c", line=1427,
level=40, status=0, s=0x0, r=0x0, pool=0x0,
fmt=0x80ac752 "%s: could not open document config file %s",
args=0xbfbfdb44 "R...") at log.c:349
#4 0x8076996 in ap_log_error (file=0x80ac2d0 "config.c", line=1427,
level=40,
status=0, s=0x0,
fmt=0x80ac752 "%s: could not open document config file %s") at
log.c:466
#5 0x8075b1a in ap_process_resource_config (s=0x80cce3c,
fname=0x80ad37b "conf/httpd.conf", conftree=0x80b7ba0,
p=0x80cc00c,
ptemp=0x810e00c) at config.c:1427
#6 0x80760e0 in ap_read_config (process=0x80c903c, ptemp=0x810e00c,
confname=0x80ad37b "conf/httpd.conf", conftree=0x80b7ba0) at
config.c:1685
#7 0x8077454 in main (argc=1, argv=0xbfbfdc88) at main.c:383
#8 0x8058411 in _start ()
(gdb)
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server config.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> The core does make an explicit call to setup the stderr log file. The
> problem is finding the error log when we don't have a server_rec.
simple: global variable in log.c to hold the handle to the stderr log file
> We
> can't just use stderr, because on Windows, we don't have stderr. There
> are definite problems with this direction, but since we can't use NULL
> pools we need to get a pool from someplace. I had hoped that we would
> have access to some global pool, which could be used for this, but
> unfortunately, all of the global pools were removed.
This assumes that we have to create the stderr log file on the fly,
which isn't the case.
>
> Then I had hoped that we could use something from the process_rec, but
> that too isn't global. While I agree that globals are in general a bad
> idea, in some cases, they are incredibly useful. :-(
>
> > Also (maybe you can confirm for me), I'm not 100% sure this need is
> > limited to Apache core code. I fear that third-party modules must
> > also know when to call ap_log_perror().
>
> This should just be core code, and those modules that implement pre_config
> functions.
translation: not just core code
> Once we get to the post_config phase, we have a
> server_rec. As for the config directives, those should be returning the
> log messages to the caller, so those shouldn't be an issue. Of course,
> there has already been one problem reported to me, and I am looking into
> how to fix it, although I don't see a good solution.
>
> Basically, when we determine that we can't setgid to (unsigned int)-1, we
> seg fault. We don't have a pool in this code, so we can't just convert to
> ap_log_perror. I am really close to a loss as far as how to solve
> this.
Very early in init, main() can call a function which sets up the
stderr log file and saves a handle to it in a global variable
accessible by log.c functions.
I hope we don't change any more ap_log_error() calls to the version
which takes a pool parameter.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server config.c
Posted by rb...@covalent.net.
> > Modified: server config.c
> > Log:
> > When we are starting the server, we have a pool that can be used to open
> > the error log. Rather than try to log a regular error, log an error with
> > the pool that we have, so that we can open stderr successfully.
>
> I'm a bit uncomfortable with this direction.
>
> Shouldn't main() make some explicit call to explicitly set up the
> stderr log file and avoid the need to change the log calls? As it is,
> we'll be converting ap_log_error() calls over time as folks find
> segfaults in obscure paths at initialization.
The core does make an explicit call to setup the stderr log file. The
problem is finding the error log when we don't have a server_rec. We
can't just use stderr, because on Windows, we don't have stderr. There
are definite problems with this direction, but since we can't use NULL
pools we need to get a pool from someplace. I had hoped that we would
have access to some global pool, which could be used for this, but
unfortunately, all of the global pools were removed.
Then I had hoped that we could use something from the process_rec, but
that too isn't global. While I agree that globals are in general a bad
idea, in some cases, they are incredibly useful. :-(
> Also (maybe you can confirm for me), I'm not 100% sure this need is
> limited to Apache core code. I fear that third-party modules must
> also know when to call ap_log_perror().
This should just be core code, and those modules that implement pre_config
functions. Once we get to the post_config phase, we have a
server_rec. As for the config directives, those should be returning the
log messages to the caller, so those shouldn't be an issue. Of course,
there has already been one problem reported to me, and I am looking into
how to fix it, although I don't see a good solution.
Basically, when we determine that we can't setgid to (unsigned int)-1, we
seg fault. We don't have a pool in this code, so we can't just convert to
ap_log_perror. I am really close to a loss as far as how to solve this.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server config.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@apache.org writes:
> rbb 00/12/31 16:13:41
>
> Modified: server config.c
> Log:
> When we are starting the server, we have a pool that can be used to open
> the error log. Rather than try to log a regular error, log an error with
> the pool that we have, so that we can open stderr successfully.
I'm a bit uncomfortable with this direction.
Shouldn't main() make some explicit call to explicitly set up the
stderr log file and avoid the need to change the log calls? As it is,
we'll be converting ap_log_error() calls over time as folks find
segfaults in obscure paths at initialization.
Also (maybe you can confirm for me), I'm not 100% sure this need is
limited to Apache core code. I fear that third-party modules must
also know when to call ap_log_perror().
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...