httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: CGI's failing with WROWE_2_0_45_RC1 on Solaris 8 w/ worker mp m
Date Wed, 26 Mar 2003 13:19:54 GMT
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.

View raw message