I am getting a reproducible crash (segfaults) on my system using Apache 1.3.27 (RH 7.3 RPM) and PHP 4.3.0 (my custom RPM). PHP was built with the following options:

        --enable-force-cgi-redirect
        --enable-debug
        --enable-pic
        --disable-rpath
        --enable-inline-optimization
        --with-bz2
        --with-db3
        --with-curl
        --with-dom=%{_prefix}
        --with-exec-dir=%{_bindir}
        --with-freetype-dir=%{_prefix}
        --with-png-dir=%{_prefix}
        --with-gd
        --enable-gd-native-ttf
        --with-ttf
        --with-gdbm
        --with-gettext
        --with-ncurses
        --with-gmp
        --with-iconv
        --with-jpeg-dir=%{_prefix}
        --with-mm
        --with-openssl
        --with-png
        --with-pspell
        --with-regex=system
        --with-xml
        --with-expat-dir=%{_prefix}
        --with-zlib
        --with-layout=GNU
        --enable-bcmath
        --enable-debugger
        --enable-exif
        --enable-ftp
        --enable-magic-quotes
        --enable-safe-mode
        --enable-sockets
        --enable-sysvsem
        --enable-sysvshm
        --enable-discard-path
        --enable-track-vars
        --enable-trans-sid
        --enable-yp
        --enable-wddx
        --without-oci8
        --with-imap=shared
        --with-imap-ssl
        --with-kerberos=/usr/kerberos
        --with-ldap=shared
        --with-mysql=shared,%{_prefix}
        --with-pgsql=shared
        --with-snmp=shared,%{_prefix}
        --with-snmp=shared
        --enable-ucd-snmp-hack
        --with-unixODBC=shared
        --enable-memory-limit
        --enable-bcmath
        --enable-shmop
        --enable-versioning
        --enable-calendar
        --enable-dbx
        --enable-dio
        --enable-mbstring
        --enable-mbstr-enc-trans

(please excuse the spec file variables; they are just pathnames so I left them in)

Running apache in the debugger yields the following trace:

0  0x4207b524 in chunk_realloc () from /lib/i686/libc.so.6
#1  0x4207b2f8 in realloc () from /lib/i686/libc.so.6
#2  0x4202b65c in __add_to_environ () from /lib/i686/libc.so.6
#3  0x4202b33f in putenv () from /lib/i686/libc.so.6
#4  0x4050cb5c in object.2 () from /etc/httpd/modules/libphp4.so
#5  0x405b3493 in object.2 () from /etc/httpd/modules/libphp4.so
#6  0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#7  0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#8  0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#9  0x405b8cae in object.2 () from /etc/httpd/modules/libphp4.so
#10 0x4059e34c in object.2 () from /etc/httpd/modules/libphp4.so
#11 0x405718a6 in object.2 () from /etc/httpd/modules/libphp4.so
#12 0x405bb61a in object.2 () from /etc/httpd/modules/libphp4.so
#13 0x405bc22b in object.2 () from /etc/httpd/modules/libphp4.so
#14 0x405bc291 in object.2 () from /etc/httpd/modules/libphp4.so
#15 0x080547cd in ap_invoke_handler ()
#16 0x0806769c in process_request_internal ()
#17 0x40271d33 in handle_dir () from /etc/httpd/modules/mod_dir.so
#18 0x080547cd in ap_invoke_handler ()
#19 0x0806769c in process_request_internal ()
#20 0x08067713 in ap_process_request ()
#21 0x0805f867 in child_main ()
#22 0x0805fa0a in make_child ()
#23 0x0805fb4d in startup_children ()
#24 0x080601a0 in standalone_main ()
#25 0x08060aa3 in main ()
#26 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

(I don't understand the large sequence of object.2 function references....debugging *is* compiled into the PHP library)

What is odd is that I have another server, almost identically configured (same RPMs, etc) that does *not* have these crashes. And then it dawned on me. The server that crashes runs IMP through an SSL connection whereas the other does not. I suspect the putenv() call is related to following in my SSL virtual host:

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

(this might also explain why I have trouble causing the crash with Mozilla...). I'd like to think this is an Apache bug but I don't have crashes accesing for any other part of the site with SSL, so PHP seems to at the very least make the bug surface.