Here is a dump of the cgi_req_t (64-bit Solaris):- 0xffffffff7ffff770: 0x00000001 0x00000000 0x00000000 0x000004d1 0xffffffff7ffff780: 0x00000000 0x00000000 0x00000000 0x00000000 0xffffffff7ffff790: 0x00000000 0x00000000 0x00000000 0x00000051 0xffffffff7ffff7a0: 0x00000000 0x0000002d 0x00000000 0x0000000b 0xffffffff7ffff7b0: 0x00000000 0x00000021 0x00000000 0x00000000 0xffffffff7ffff7c0: 0x00000000 0x00000000 0x00000004 0x00000000 0xffffffff7ffff7d0: 0x00000001 0x002103f0 0x00000001 0x0020eef0 0xffffffff7ffff7e0: 0x00000000 0x00000000 0x00000001 0x0020ec50 0xffffffff7ffff7f0: 0x00000001 0x00000004 0x00000004 0x00000004 0xffffffff7ffff800: 0x00000001 0x00210990 0x00000001 0x0020f2c8 0xffffffff7ffff810: 0x00000001 0x0020f288 0x00000000 0x00000002 0xffffffff7ffff820: 0x00000001 0x0020cc40 0x00000001 0x0015e238 0xffffffff7ffff830: 0x00000001 0x0015b958 0x00000001 0x0020ebe8 0xffffffff7ffff840: 0x00000010 0x00000012 0x00000000 0x00000009 0xffffffff7ffff850: 0x00000008 0x00000001 0x00000000 0x00000000 0xffffffff7ffff860: 0x00000000 0x0000736f 0x636b0000 0x00000000 0xffffffff7ffff870: 0x00000000 0x00000000 0x00000000 0x00000000 0xffffffff7ffff880: 0x00000000 0x00000000 0x00000000 0x00000000 0xffffffff7ffff890: 0x00000000 0x00000000 0x00000000 0x00000000 0xffffffff7ffff8a0: 0x00000000 0x00000000 0x00000000 0x00000000 0xffffffff7ffff8b0: 0x00000000 0x00000000 0x00000000 0x00000000 0xffffffff7ffff8c0: 0x00000000 0x0012c2c8 0x00000001 0x0015b958 0xffffffff7ffff8d0: 0x00000001 0x0015b958 0xffffffff 0x7c50c0b8 0xffffffff7ffff8e0: 0x00000000 0x00000000 0xffffffff 0x7c409fe8 0xffffffff7ffff8f0: 0x00000000 0x00000000 0x00000000 0x00000000
Hope this helps... cheers, Steve > -----Original Message----- > From: Jeff Trawick [SMTP:[EMAIL PROTECTED] > Sent: Wednesday, March 26, 2003 1:20 PM > To: [EMAIL PROTECTED] > Subject: Re: CGI's failing with WROWE_2_0_45_RC1 on Solaris 8 w/ > worker mp m > > 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. > 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.
