ID:               21948
 Comment by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
 Status:           Feedback
 Bug Type:         Reproducible crash
 Operating System: RedHat Linux 7.3
 PHP Version:      4.3.0
 New Comment:

I spoke too soon, the crash is still there. Am attempting to get a core
file now to generate another backtrace to see if its the same problem
or not.

bug 21804 seems like it may be related to this issue as well.


Previous Comments:
------------------------------------------------------------------------

[2003-01-29 14:05:43] [EMAIL PROTECTED]

It is compiled with --enable-debug (see config list above), which is
why I made the note that the backtrace was somewhat baffling. I ran gdb
across libphp4.so just to confirm that it  does indeed load debugging
symbols so they ARE there.

FYI I removed the SetEnvIf directive and the crashes have gone away it
seems.

------------------------------------------------------------------------

[2003-01-29 13:56:17] [EMAIL PROTECTED]

Please compile PHP with --enable-debug, that will result in more
detailed backtraces.

------------------------------------------------------------------------

[2003-01-29 12:32:18] [EMAIL PROTECTED]

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.


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=21948&edit=1

Reply via email to