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.
