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?

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.