S/W Environment: HPUX 11.00, Apache 2.0 (worker model) , PHP 4.2.3 This one seems to be a hard to trace problem but easily reproducible. Basically, an Apache thread servicing a PHP request crashes when you access the main page (index.php) of phpMyAdmin.
An entry similar to the foll. is seen in the Apache error_log for every access attempt... [notice] child pid 26712 exit signal Illegal instruction (4) One user has also provided us with some informative gdb analysis of the problem that I have pasted to the end of this email. PS: This problem does not show up in Apache 1.3 or Apache 2.0(prefork model). That is why I suspect the problem to lie somewhere in the threading. Different people seem to have run into this problem but in different ways. But this way it seems to be easily reproducible. Anyway I have gone ahead and filed a bug report without this gdb analysis. Regards, -- Roshan Naik HP-UX Apache Web Server Suite Team. 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? 0x80000000 - 0x7eedd030 = 0x01122FD0 maxssiz 0X01000000 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: 0x00000000 (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. Maybe the PHP module needs a larger thread stack. ===================================================================== -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
