Re: CGI's failing with WROWE_2_0_45_RC1 on Solaris 8 w/ worker mp m

["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.
>