#21855 [Com]: Likely threading issue: Crash when using Apache 2.0 (worker model)
ID: 21855 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: HPUX 11.00 PHP Version: 4.2.3 New Comment: I have verified that this problem exists in 4.3.0 too. This is definitely a terrible bug (most likely with the threading somewhere). And is being exposed repeatedly by many people. Hopefully someone will look into this. I had provided with a stack trace with php4.2.3 in my first post. Previous Comments: [2003-01-24 13:19:09] [EMAIL PROTECTED] First of all please try PHP 4.3.0 or better yet the latest (stable) snapshot. When you compile it, please use --enable-debug, as that would produce more meaningful backtraces if the code cores. [2003-01-24 12:45:46] [EMAIL PROTECTED] No modules (besides the default) have been compiled into php. Why has the bug report status been changed to Feedback ? [2003-01-24 09:50:11] [EMAIL PROTECTED] What php modules do you have compiled? [2003-01-23 20:24:24] [EMAIL PROTECTED] Following Problem noticed when using Apache 2.0 built with the worker model. This problem is not seen on Apache 2.0 (prefork) or Apache 1.3. A crash is noticed with the following entry in the Apache error_log when main page (index.php) of phpMyAdmin is accessed... [notice] child pid 26712 exit signal Illegal instruction (4) -- GDB analysis -- Here's a short analysis. I attached with gdb to the httpd process and then reloaded the page: Program received signal SIGBUS, Bus error. [Switching to thread 2 (system thread 4353)] 0xc0208700 in __thread_mutex_lock+0x10 () from /usr/lib/libc.2 (gdb) info threads 27 system thread 4378 0xc01f9cc8 in _semop_sys+0x10 () from /usr/lib/libc.2 26 system thread 4377 warning: reading `r3' register: No data 0xc01f5100 in __ksleep+0x10 () from /usr/lib/libc.2 : 0xc01f5100 in __ksleep+0x10 () from /usr/lib/libc.2 3 system thread 4354 warning: reading `r3' register: No data 0xc01f5100 in __ksleep+0x10 () from /usr/lib/libc.2 * 2 system thread 4353 0xc0208700 in __thread_mutex_lock+0x10 () from /usr/lib/libc.2 1 system thread 4351 warning: reading `r3' register: No data 0xc01f6ed0 in _read_sys+0x10 () from /usr/lib/libc.2 (gdb) bt #0 0xc0208700 in __thread_mutex_lock+0x10 () from /usr/lib/libc.2 #1 0xc0184690 in mallinfo+0xa04 () from /usr/lib/libc.2 #2 0xc0182330 in __thread_callback_np+0x624 () from /usr/lib/libc.2 #3 0xc0187e7c in malloc+0x198 () from /usr/lib/libc.2 #4 0xc267fb24 in virtual_file_ex+0xb4 () from /opt/hpapache2/modules/libphp4.so #5 0xc25b5d64 in expand_filepath+0x74 () from /opt/hpapache2/modules/libphp4.so #6 0xc25b4d78 in php_fopen_and_set_opened_path+0x78 () from /opt/hpapache2/modules/libphp4.so #7 0xc25b58a8 in php_fopen_with_path+0x2f0 () from /opt/hpapache2/modules/libphp4.so #8 0xc25b5b70 in php_fopen_url_wrapper+0x250 () from /opt/hpapache2/modules/libphp4.so #9 0xc25b4f14 in php_fopen_wrapper+0x124 () from /opt/hpapache2/modules/libphp4.so #10 0xc25b031c in php_fopen_wrapper_for_zend+0x84 () from /opt/hpapache2/modules/libphp4.so #11 0xc2567034 in open_file_for_scanning+0x54 () from /opt/hpapache2/modules/libphp4.so #12 0xc2567368 in compile_file+0xc8 () from /opt/hpapache2/modules/libphp4.so #13 0xc2567644 in compile_filename+0xac () from /opt/hpapache2/modules/libphp4.so #14 0xc258acd8 in execute+0x7ad8 () from /opt/hpapache2/modules/libphp4.so (gdb) disas 0xc02086f0 __thread_mutex_lock: stw %rp,-0x14(%sp) 0xc02086f4 __thread_mutex_lock+4: ldo 0x40(%sp),%sp 0xc02086f8 __thread_mutex_lock+8: addil L'-0x800,%r19,%r1 0xc02086fc __thread_mutex_lock+12:ldw 0x390(%r1),%r24 0xc0208700 __thread_mutex_lock+16:stw %r19,-0x20(%sp) 0xc0208704 __thread_mutex_lock+20:ldw 0(%r24),%r31 : (gdb)p/x $sp $1 = 0x7eedd030 (gdb) x/x $sp 0x7eedd030: Error accessing memory address 0x7eedd030: Bad address. Is 0x7eedd030 a valid stack address? 0x8000 - 0x7eedd030 = 0x01122FD0 maxssiz 0X0100 So not for the process stack. Maybe it is within a thread stack? (gdb) info frame Stack level 0, frame at 0x7eedcff0: pcoqh = 0xc0208700 in __thread_mutex_lock; saved pcoqh 0xc0184690 called by frame at 0x7eedceb0 Arglist at 0x7eedcff0, args:last known Locals at 0x7eedcff0, Previous frame's sp cis 0x7eedcff0 == valid stack Saved registers:address rp at 0x7eedcfdc (gdb) x/x 0x7eedcff0 0x7eedcff0: 0x (gdb) x/x 0x7eedd000 0x7eedd000: Error accessing memory address 0x7eedd000:
#21855 [NEW]: Likely threading issue: Crash when using Apache 2.0 (worker model)
From: [EMAIL PROTECTED] Operating system: HPUX 11.00 PHP version: 4.2.3 PHP Bug Type: Reproducible crash Bug description: Likely threading issue: Crash when using Apache 2.0 (worker model) Following Problem noticed when using Apache 2.0 built with the worker model. This problem is not seen on Apache 2.0 (prefork) or Apache 1.3. A crash is noticed with the following entry in the Apache error_log when main page (index.php) of phpMyAdmin is accessed... [notice] child pid 26712 exit signal Illegal instruction (4) -- GDB analysis -- Here's a short analysis. I attached with gdb to the httpd process and then reloaded the page: Program received signal SIGBUS, Bus error. [Switching to thread 2 (system thread 4353)] 0xc0208700 in __thread_mutex_lock+0x10 () from /usr/lib/libc.2 (gdb) info threads 27 system thread 4378 0xc01f9cc8 in _semop_sys+0x10 () from /usr/lib/libc.2 26 system thread 4377 warning: reading `r3' register: No data 0xc01f5100 in __ksleep+0x10 () from /usr/lib/libc.2 : 0xc01f5100 in __ksleep+0x10 () from /usr/lib/libc.2 3 system thread 4354 warning: reading `r3' register: No data 0xc01f5100 in __ksleep+0x10 () from /usr/lib/libc.2 * 2 system thread 4353 0xc0208700 in __thread_mutex_lock+0x10 () from /usr/lib/libc.2 1 system thread 4351 warning: reading `r3' register: No data 0xc01f6ed0 in _read_sys+0x10 () from /usr/lib/libc.2 (gdb) bt #0 0xc0208700 in __thread_mutex_lock+0x10 () from /usr/lib/libc.2 #1 0xc0184690 in mallinfo+0xa04 () from /usr/lib/libc.2 #2 0xc0182330 in __thread_callback_np+0x624 () from /usr/lib/libc.2 #3 0xc0187e7c in malloc+0x198 () from /usr/lib/libc.2 #4 0xc267fb24 in virtual_file_ex+0xb4 () from /opt/hpapache2/modules/libphp4.so #5 0xc25b5d64 in expand_filepath+0x74 () from /opt/hpapache2/modules/libphp4.so #6 0xc25b4d78 in php_fopen_and_set_opened_path+0x78 () from /opt/hpapache2/modules/libphp4.so #7 0xc25b58a8 in php_fopen_with_path+0x2f0 () from /opt/hpapache2/modules/libphp4.so #8 0xc25b5b70 in php_fopen_url_wrapper+0x250 () from /opt/hpapache2/modules/libphp4.so #9 0xc25b4f14 in php_fopen_wrapper+0x124 () from /opt/hpapache2/modules/libphp4.so #10 0xc25b031c in php_fopen_wrapper_for_zend+0x84 () from /opt/hpapache2/modules/libphp4.so #11 0xc2567034 in open_file_for_scanning+0x54 () from /opt/hpapache2/modules/libphp4.so #12 0xc2567368 in compile_file+0xc8 () from /opt/hpapache2/modules/libphp4.so #13 0xc2567644 in compile_filename+0xac () from /opt/hpapache2/modules/libphp4.so #14 0xc258acd8 in execute+0x7ad8 () from /opt/hpapache2/modules/libphp4.so (gdb) disas 0xc02086f0 __thread_mutex_lock: stw %rp,-0x14(%sp) 0xc02086f4 __thread_mutex_lock+4: ldo 0x40(%sp),%sp 0xc02086f8 __thread_mutex_lock+8: addil L'-0x800,%r19,%r1 0xc02086fc __thread_mutex_lock+12:ldw 0x390(%r1),%r24 0xc0208700 __thread_mutex_lock+16:stw %r19,-0x20(%sp) 0xc0208704 __thread_mutex_lock+20:ldw 0(%r24),%r31 : (gdb)p/x $sp $1 = 0x7eedd030 (gdb) x/x $sp 0x7eedd030: Error accessing memory address 0x7eedd030: Bad address. Is 0x7eedd030 a valid stack address? 0x8000 - 0x7eedd030 = 0x01122FD0 maxssiz 0X0100 So not for the process stack. Maybe it is within a thread stack? (gdb) info frame Stack level 0, frame at 0x7eedcff0: pcoqh = 0xc0208700 in __thread_mutex_lock; saved pcoqh 0xc0184690 called by frame at 0x7eedceb0 Arglist at 0x7eedcff0, args:last known Locals at 0x7eedcff0, Previous frame's sp cis 0x7eedcff0 == valid stack Saved registers:address rp at 0x7eedcfdc (gdb) x/x 0x7eedcff0 0x7eedcff0: 0x (gdb) x/x 0x7eedd000 0x7eedd000: Error accessing memory address 0x7eedd000: Bad address. So 0x7eedcff0 is valid, but 0x7eedd000 is not (only 16 bytes difference). Looks like we crossed the end of the thread stack. -- Edit bug report at http://bugs.php.net/?id=21855edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21855r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21855r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21855r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21855r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21855r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21855r=support Expected behavior: http://bugs.php.net/fix.php?id=21855r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21855r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21855r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21855r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21855r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21855r=dst IIS Stability:
Bug #16956: Debug symbols enabled by default in build
From: [EMAIL PROTECTED] Operating system: HPUX 11.20 PHP version: 4.1.2 PHP Bug Type: *Compile Issues Bug description: Debug symbols enabled by default in build The -g option is passed by default to the compiler even if --enable-debug is NOT used. Using --disable-debug is of no help[ either. Compiling PHP against Apache 2.0. as follows ./configure --with-apxs2=/opt/apache2/bin/apxs \ --prefix=/opt/apache2/php make When performing make , every compilation command has -g The following doesnt help either. ./configure --with-apxs2=/opt/apache2/bin/apxs \ --prefix=/opt/apache2/php \ --diable-debug make -- Edit bug report at http://bugs.php.net/?id=16956edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16956r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16956r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16956r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16956r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16956r=support Expected behavior: http://bugs.php.net/fix.php?id=16956r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16956r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16956r=submittedtwice
