php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21855 Likely threading issue: Crash when using Apache 2.0 (worker model)
Submitted: 2003-01-23 20:24 UTC Modified: 2003-07-19 08:11 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:3 (100.0%)
From: roshan_naik at hp dot com Assigned:
Status: Closed Package: Apache2 related
PHP Version: 4.3.0 OS: HPUX 11.00
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: roshan_naik at hp dot com
New email:
PHP Version: OS:

 

 [2003-01-23 20:24 UTC] roshan_naik at hp dot com
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. 

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-24 09:50 UTC] iliaa@php.net
What php modules do you have compiled?
 [2003-01-24 12:45 UTC] roshan_naik at hp dot com
No modules (besides the default) have been compiled into php. 

Why has the bug report status been changed to "Feedback" ?
 [2003-01-24 13:19 UTC] iliaa@php.net
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-02-03 20:33 UTC] roshan_naik at hp dot com
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.
 [2003-02-04 05:18 UTC] sniper@php.net
Updated version. 

roshan_naik@hp.com: When you reply to your own bug report,
PLEASE use the http://bugs.php.net/?id=21855&edit=2 link.


 [2003-07-11 00:02 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Also, get the latest Apache2 version too..

 [2003-07-18 18:51 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2003-07-19 08:11 UTC] sniper@php.net
This should be fixed in CVS now.


 [2004-01-28 13:08 UTC] js at iksz dot hu
Tested with FreeBSD 5.2, PHP4.3.4, Apache2.0.48.  It 
drops dead with worker and perchild, but works well with 
prefork.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 21:01:27 2024 UTC