I am running php 4.04pl1 compiled as an apache 1.3  module with support for curl, pgsql, and zlib.  It seems that the module crashes, causing httpd processes to seg fault when a POST request is made without a content-type header.  It seems that the crash only occurs after a normal POST with a content-type header is followed by one without.  To reproduce the crash, I simply make a POST request to a php script that does pretty much nothing( usually just printing a statement indicating that it ran ) with a browser(Netscape 4.6.2 or lynx-2.82.) and then run a program that I wrote that sends a POST request w/o the Content-Type header.  Sometimes this step must be done several times until the same apache child process that I hit with the browser receives the bad request.  Eventually, after running this program for a while one apache child process dies for each hit I made from the browser.  This only occurs with php scripts and apache does not give me a core dump that i can analyze to give you more info.  

Check this url for information how to generate a GDB backtrace:

http://bugs.php.net/bugs-generating-backtrace.php

(It has info what to do when you don't get any core dumps)

Also, remember that you have to configure PHP with --enable-debug
to get useful backtraces.

--Jani

Here is the backtrace that I got by running httpd under gdb:

Program received signal SIGSEGV, Segmentation fault.
php_std_post_handler (content_type_dup=0x0, arg=0x80e1e74) at /usr/local/include/bits/string2.h:1051
1051      while (*__s == __sep)
(gdb) bt
#0  php_std_post_handler (content_type_dup=0x0, arg=0x80e1e74) at /usr/local/include/bits/string2.h:1051
#1  0x4047f430 in sapi_handle_post (arg=0x80e1e74) at SAPI.c:101
#2  0x40482a38 in php_treat_data (arg=0, str=0x0, destArray=0x0) at php_variables.c:251
#3  0x4047d062 in php_hash_environment () at main.c:1039
#4  0x4047c7c4 in php_request_startup () at main.c:645
#5  0x40479aec in apache_php_module_main (r=0x8052210, display_source_mode=0) at sapi_apache.c:66
#6  0x4047a581 in send_php (r=0x8052210, display_source_mode=0, filename=0x0) at mod_php4.c:516
#7  0x4047a5c6 in send_parsed_php (r=0x8052210) at mod_php4.c:527
#8  0x400252b9 in __bam_rsearch (dbp=0x8052210, recnop=0x4007bab0, flags=3221223944, stop=1073991020, exactp=0x40085130)
    at btree/bt_rsearch.c:235
#9  0x4003d353 in __ham_newpage_recover (logp=0x8052210, dbtp=0x1, lsnp=0x0, redo=1073992604, info=0x40085130)
    at hash/hash_rec.c:279
#10 0x4003d3d0 in __ham_newpage_recover (logp=0x8052210, dbtp=0x4, lsnp=0x8052210, redo=1073950625, info=0x40085130)
    at hash/hash_rec.c:295
#11 0x40032f23 in __db_big_recover (logp=0x0, dbtp=0x400310f8, lsnp=0x0, redo=1073950904, info=0x40085130) at db/db_rec.c:306
#12 0x4003313a in __db_ovref_recover (logp=0x804e1e0, dbtp=0x0, lsnp=0x3a9f9ddf, redo=1073951340, info=0x40085130)
    at db/db_rec.c:360
#13 0x400332e7 in __db_relink_recover (logp=0x5, dbtp=0x804e1e0, lsnp=0xbffffb38, redo=1073953267, info=0x40085130)
    at db/db_rec.c:407
#14 0x40033a50 in __db_rattach (infop=0x2) from /lib/libdb.so.3
#15 0x40034493 in __db_rgrow (infop=0x2, new_size=3221224484) at common/db_region.c:735
#16 0x8049476 in ap_gcvt ()
#17 0x401421eb in __fgetgrent_r (stream=0x8049454, resbuf=0x2, buffer=0xbffffc24 "0???N???", buflen=134517128,
    result=0x804a614) at fgetgrent_r.c:72

Here is my php.ini file:

max_execution_time = 300     
include_path="." 
zend_extension="/usr/local/Zend/ZendDebugger.so"         

I installed the demo of the Zend php IDE, and this could explain the strangeness of the backtrace.

Fixed in CVS.

--Jani