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