#44342 [Fbk->Opn]: PHP crashes Apache 2.2
| From: | i dot galic at brainsware dot org | Date: | Wed, 12 Mar 2008 13:41:41 +0000 |
| Subject: | #44342 [Fbk->Opn]: PHP crashes Apache 2.2 | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-123227@lists.php.net to get a copy of this message | ||
ID: 44342
User updated by: i dot galic at brainsware dot org
Reported By: i dot galic at brainsware dot org
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Solaris 10, Update 6, Sparc 64
PHP Version: 5.2.5
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2008-03-11 21:53:52] 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-09 00:36:21] 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-05 19:54:13] 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
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=44342&edit=1