php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #44342 PHP crashes Apache 2.2
Submitted: 2008-03-05 19:54 UTC Modified: 2008-03-17 20:55 UTC
From: i dot galic at brainsware dot org Assigned:
Status: Not a bug Package: Reproducible crash
PHP Version: 5.2.5 OS: Solaris 10, Update 6, Sparc 64
Private report: No CVE-ID: None
View Developer Edit
 [2008-03-05 19:54 UTC] i dot galic at brainsware dot org 
Description:
------------
Running a PHP Application (Zabbix) on Apache 2.2 with PHP 5.2.5 with 
Suhosin-Patch on Solaris 10, Update 6, Sparc, compiled for 64 bit.
I do not know exactly how to reproduce the crash, I have however 
however several core dumps all of which look the same.


Reproduce code:
---------------
I built PHP http://dpaste.com/hold/38122/ (please consider that the paste will only retain for 30 days after nobody looked at it.)

The Bug report tool says: "Always disable any Zend or other 3rd party extensions (Turck MMCache, ionCube loader, Xdebug, APC) before submitting a *PHP* bug."

I am not sure if
--enable-maintainer-zts --enable-zend-multibyte 
are part of this restriction, as they are provided by standard PHP or Suhosin in my for that matter, as it does (unfortunately) not interfere here (see stack trace).



Actual result:
--------------
core 'core_asp1inmon001_httpd_1_12_1204718387_521' of 
521:      /opt/baw/bin/httpd -k start
 ffffffff7d6619dc t_splay (1003f7200, 69, 188c88, 68, 0, 1003f7220) 
+ 24
 ffffffff7d66182c t_delete (1003f7200, a1, 188828, ffffffff7d661ca4, 
ffffffff7d7ea000, 0) + 60
 ffffffff7d6613f8 realfree (1003f7188, 69, 188c88, 68, 
ffffffff7d7ea000, 1003f7188) + 94
 ffffffff7d661ca4 _free_unlocked (ffffffff7d7fb060, 2000, 2280, 
ffffffff7d7f9b08, ffffffff7d7ea000, 1003fbdb0) + c0
 ffffffff7d661bcc free (1003fbdb0, 2270, 188458, ffffffff776cfcc0, 
ffffffff7d7ea000, 2000) + 30
 ffffffff776b1014 zend_function_dtor (1004539a0, 10041e488, 0, 0, 
10017c170, 10041e4b8) + 12c
 ffffffff776cfcc0 zend_hash_destroy (1001e7d50, 1, 100453930, 
100453aa0, ffffffff77a458b0, 0) + 28
 ffffffff776bdea0 ???????? (10026bbb0, ffffffff77ad7798, 387a44, 
800, 0, 9b8)
 ffffffff77635d10 tsrm_shutdown (91470, ffffffff77ad6d20, a0, 28, 
ffffffff77a458b0, 0) + b0
 ffffffff77748738 ???????? (0, ffffffff77642340, ffffffff77a458b0, 
504c8, 2fd1a4, 50400)
 ffffffff7e51ce6c apr_pool_destroy (1003c33f8, 1003cd420, 0, 0, 
1003c34c0, 0) + 26c
 000000010005315c ???????? (100178000, 100175000, 2, 100175, 100000, 
100178)
 ffffffff7d6d23c4 __sighndlr (f, 0, ffffffff7fff5040, 10005312c, 0, 
e) + c
 ffffffff7d6c6630 call_user_handler (ffffffff7ae00200, 
ffffffff7ae00200, ffffffff7fff5040, 0, 0, 0) + 3e0
 ffffffff7d6d31b0 _read (e, 1009cbf20, 4000, 0, ffffffff7810c370, 
ffffffff780719a8) + c
 ffffffff77e6a6a4 ???????? (1009cbe20, 1009cff30, 4, 0, 1, 7)
 ffffffff77e6c8fc ???????? (1009cb920, ffffffff7fff55f8, 1009cff30, 
4, ffffffff7810c370, ffffffff780719a8)
 ffffffff77e6cc3c ???????? (1009cb920, ffffffff77e62528, 
ffffffff780719a8, 10c494, 1, 1009cb920)
 ffffffff77e622f8 ???????? (1009cb920, 100766c50, 110538, 1009cbe20, 
ffffffff7810c370, ffffffff780719a8)
 ffffffff77e6639c ???????? (1009cb920, ffffffff77e62528, 
ffffffff780719a8, 10c494, 1, 1009cb920)
 ffffffff77e6686c ???????? (1009cb920, 100766c50, 13f, 
ffffffff77e66380, ffffffff7810c370, ffffffff780719a8)
 ffffffff78107978 ???????? (10022db88, e, ffffffffffffffff, 0, 1, 
1009716e0)
 ffffffff78107c24 ???????? (2, 1009716e0, 0, 0, 1, 10017c170)
 ffffffff776f8efc ???????? (ffffffff7fff5db0, 10017c170, 
ffffffff78107b28, 0, 10090b9a0, ffffffff7fff5db0)
 ffffffff776f8a7c execute (100317680, 10017c170, 10026c390, 188, 
10026c390, 10090b9a0) + 2ec
 ffffffff776f90a4 ???????? (ffffffff7fff6d68, 10017c170, 100317680, 
0, 1003d4870, ffffffff7fff8920)
 ffffffff776f8a7c execute (100317680, 10017c170, 10026c390, 2a0, 
10026c390, 1003d4870) + 2ec
 ffffffff776bfd6c zend_execute_scripts (8, 10017c170, 0, 
ffffffff776f8790, ffffffff77ad76e0, 0) + 1ac
 ffffffff7764285c php_execute_script (ffffffff7fff9158, 100283470, 
48, ffffffff77a458b0, 10017c170, 100317680) + 364
 ffffffff7774969c ???????? (1003cb4a8, 72, 61, 100000, 
ffffffff78e10bf0, ffffffff78d10918)
 000000010003b548 ap_run_handler (1003cb4a8, 3, 1001e4f20, 
1001e4f68, 100178, 100000) + 3c
 000000010003bf8c ap_invoke_handler (1003cb4a8, 1001e5028, 
1001e46f8, fffffffeffe1b908, 0, 0) + dc
 000000010004e358 ap_process_request (1003cb4a8, 4, 1003cb4a8, 0, 
100175000, 100000) + 58
 000000010004a5a0 ???????? (1003c5768, 100178000, 0, 100175000, 
100175000, 1000)
 00000001000450c0 ap_run_process_connection (1003c5768, 1003c5478, 
1001e4b90, 1001e5380, 100178, 100000) + 3c
 0000000100053604 ???????? (1003c5768, 100178000, 100175000, 
100175a9c, 100178dd0, 100179000)
 0000000100053b70 ???????? (100000, 0, 19, 100175, 100053, 
10005312c)
 0000000100053e8c ???????? (11, 1003c2af0, 8, 100179000, 100175a7c, 
100178de0)
 000000010005471c ap_mpm_run (0, 100175, 5, 100179000, 100175a94, 
100175000) + 81c
 000000010001dc44 main (1117e, 100000, 100193b18, 100173000, 0, 
100175000) + a5c
 000000010001d0bc _start (0, 0, 0, 0, 0, 0) + 17c

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-03-09 00:36 UTC] i dot galic at brainsware dot org 
So far my digging has born the idea that the reason is --enable-maintainer-zts, which enforces thread safety upon PHP by killing it ruthlessly, if it just so happens to behave in a thread-unsafe-manner.
Now, I still would classify this as bug, because I only have PHP core modules loaded, namely:

mysql.so
mysqli.so
pdo.so
pdo_mysql.so
bcmath.so
gd.so

php.net claims that it's core modules *are* thread safe -- unless noted otherwise. As not even the notorious gd: http://php.net/gd states to be thread-unsafe, this is either a bug, or lack of documentation.

Whatever it is, I do not like the idea that this happens after a call to a destructor. It suggests to me the possibility of a potentially exploitable buffer-overflow or an otherwise corrupted memory. So I don't quite know which of the evils to choose (I have already recompiled PHP without the -zts flag, but haven't gotten yet to test it).
 [2008-03-11 21:53 UTC] jani@php.net 
ANY 3rd party modification not coming from php.net is not supported by php.net. So please, provide the trace without suhosin. And cut down your configure line to shortest possible. And don't define any CFLAGS / etc. either.
 [2008-03-12 13:41 UTC] i dot galic at brainsware dot org 
ad suhosin: I've been use suhosin for years now, never experiencing 
any problems, that's why I patched this PHP version, too, I 
understand your standpoint though, that you do not support third 
party modules ( just a random google: suhosin thread safe: 
http://blog.php-security.org/archives/82-Suhosin-0.9.20-and-crypt-Thread-Safety-Vulnerability.html )

ad configure: I generally compile as many modules as possible, and 
prefer them shared, so I can *load* those which my 
users/applications need.
ad *FLAGS: I CAN NOT leave out the CFLAGS/LDFLAGS etc out, because 
I'm compiling with Sun's Studio 12, on Solaris 10, on a T2000, 
64bit.
Despite the festering size of 116706 lines (contrast this with 
Apache, which comes with a similar amount of modules: 23854), PHP's 
configure does not build with ./configure && make && make install 
out of the box on this platform (neither does apache, btw ;)

FYI: I recompiled PHP without --enable-maintainer-zts, and been 
running for three days now without core-dumps. For whatever that's 
worth.
Unfortunately, this is a productive system, and I do not have a test 
system for it to test it without suhosin but - 
with --enable-maintainer-zts, so I don't know what to do with this 
bug right now.
I'm building it non-the-less, if I get a system, I shall provide you 
with straces, *without* suhosin.
 [2008-03-13 12:03 UTC] jani@php.net 
Why exactly do you use --enable-maintainer-zts anyway?

# ./configure --help | grep maintainer
 --enable-maintainer-zts Enable thread safety - for code maintainers only!!

It's meant for developers to test quickly whether their changes might be causing compile problems or not. It's definately NOT meant for production use!
 [2008-03-17 13:40 UTC] i dot galic at brainsware dot org 
After a few days of waiting -- and with the new compile without the "thread-safety" -- I'm getting core dumps again:

http://dpaste.com/hold/39794/

As this look completely different, I suggest closing this ticket here - and I shall open up a new one, as soon as I can actually reproduce it.
 [2008-03-17 20:55 UTC] jani@php.net 
As you wish.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Thu Jul 17 14:04:04 2025 UTC