You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Steve Sabljak <st...@bbc.co.uk> on 2003/03/26 12:14:54 UTC
RE: CGI's failing with WROWE_2_0_45_RC1 on Solaris 8 w/ worker mp
m
Here is the backtrace from the cgi daemon's core:-
core 'core.httpd.10133.u60001' of 10133: /usr/local/apache2/bin/httpd
-f /etc/httpd2.conf
ffffffff7e100ae8 memset (0, 0, 474554202f63676a, ffffffffffffffc0,
474554202f636740, 0) + 114
ffffffff7c404784 get_req (9, 10020ec50, ffffffff7ffff810, ffffffff7ffff808,
ffffffff7ffff770, 10020ef11) + 45c
ffffffff7c40545c cgid_server (100210460, 10012c2c8, 0, 0, 0, 0) + 55c
ffffffff7c405b84 cgid_init (10012c2c8, 100156418, 10012e2d8, 10015b958,
1001f7460, 0) + 21c
000000010006af54 ap_run_post_config (10012c2c8, 100156418, 10012e2d8,
10015b958, 0, 0) + b4
00000001000766ec main (3, ffffffff7ffffcf8, ffffffff7ffffd18, 0, 0,
100000000) + 100c
000000010004f7fc _start (0, 0, 0, 0, 0, 0) + 17c
-Steve
> -----Original Message-----
> From: Steve Sabljak
> Sent: Wednesday, March 26, 2003 10:41 AM
> To: dev@httpd.apache.org
> Subject: CGI's failing with WROWE_2_0_45_RC1 on Solaris 8 w/ worker
> mpm
>
> The CGI daemon fails and does not recover with WROWE_2_0_45_RC1
> on Solaris 8 running with the worker mpm.
>
> Error log reports:-
> (3)No such process: cgid daemon is gone; is Apache terminating?:
> /path/to/cgi
>
> cheers,
> Steve
>
>
> BBCi at http://www.bbc.co.uk/
>
> This e-mail (and any attachments) is confidential and may contain
> personal views which are not the views of the BBC unless specifically
> stated.
> If you have received it in error, please delete it from your system, do
> not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately. Please note that the
> BBC monitors e-mails sent or received. Further communication will
> signify your consent to this.
>
BBCi at http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system, do
not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received. Further communication will
signify your consent to this.
Re: CGI's failing with WROWE_2_0_45_RC1 on Solaris 8 w/ worker
mp m
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Fast and possibly irrelevant observations;;
cgid_req_t grew an int log_level member, perhaps packet sizes aren't
quite right.
ap_log_error(APLOG_MARK, APLOG_ERR, err, r->server, "%s", description)
is now used to trace loglevel. Perhaps something about r->server isn't
altogether right in terms of dereferenced server_rec members in ap_log_error.
Perhpas apr_pool_userdata_set(r, ERRFN_USERDATA_KEY,
apr_pool_cleanup_null, ptrans); isn't the appropriate pool, such that
we are failing to pick up a valid *r in cgid_child_errfn()?
Bill
At 07:19 AM 3/26/2003, Jeff Trawick wrote:
>Steve Sabljak wrote:
>>Here is the backtrace from the cgi daemon's core:-
>>core 'core.httpd.10133.u60001' of 10133: /usr/local/apache2/bin/httpd
>>-f /etc/httpd2.conf
>> ffffffff7e100ae8 memset (0, 0, 474554202f63676a, ffffffffffffffc0,
>>474554202f636740, 0) + 114
>> ffffffff7c404784 get_req (9, 10020ec50, ffffffff7ffff810, ffffffff7ffff808,
>>ffffffff7ffff770, 10020ef11) + 45c
>
>get_req() doesn't call memset() directly except in the expansion of the apr_pcalloc() macro. With 0 for the first parm to memset(), it would seem that apr_palloc() returns 0 (i.e., it fails due to out-of-storage condition) which then results in memset() puking.
>
>But look at the 3rd parm to memset(), which is huge. I guess some field in cgi_req_t that controls one of the storage allocation requests is bogus, and thus the apr_palloc() returns 0 because it was told to get a bogus amount of storage.
>
>Can you dump out the storage of the 5th parm to get_req()? I guess that is 0xffffffff7ffff770. On a 32-bit Linux build, cgi_req_t is 64 bytes. Try dumping out 100 bytes just to be safe.
>
>The next step would be to guess what happens in the cgid handler to cause something bogus to be in the cgid_req_t. Hopefully knowing what is bogus would yield a theory.
>
Re: CGI's failing with WROWE_2_0_45_RC1 on Solaris 8 w/ worker mp
m
Posted by Jeff Trawick <tr...@attglobal.net>.
Steve Sabljak wrote:
> Here is the backtrace from the cgi daemon's core:-
>
> core 'core.httpd.10133.u60001' of 10133: /usr/local/apache2/bin/httpd
> -f /etc/httpd2.conf
> ffffffff7e100ae8 memset (0, 0, 474554202f63676a, ffffffffffffffc0,
> 474554202f636740, 0) + 114
> ffffffff7c404784 get_req (9, 10020ec50, ffffffff7ffff810, ffffffff7ffff808,
> ffffffff7ffff770, 10020ef11) + 45c
get_req() doesn't call memset() directly except in the expansion of the
apr_pcalloc() macro. With 0 for the first parm to memset(), it would
seem that apr_palloc() returns 0 (i.e., it fails due to out-of-storage
condition) which then results in memset() puking.
But look at the 3rd parm to memset(), which is huge. I guess some field
in cgi_req_t that controls one of the storage allocation requests is
bogus, and thus the apr_palloc() returns 0 because it was told to get a
bogus amount of storage.
Can you dump out the storage of the 5th parm to get_req()? I guess that
is 0xffffffff7ffff770. On a 32-bit Linux build, cgi_req_t is 64 bytes.
Try dumping out 100 bytes just to be safe.
The next step would be to guess what happens in the cgid handler to
cause something bogus to be in the cgid_req_t. Hopefully knowing what
is bogus would yield a theory.