PHP 5.3.6 segfault (in both apache w/mod_php and nginx w/fpm)

Question

I'm getting an obnoxious segfault in PHP 5.3.6 (compiled from source, Slackware 13.1 x86, VPS in Linode). It is happening in both apache and nginx (fpm). Finally managed to get a core dump:

0  0x083db383 in _zval_ptr_dtor ()
1  0x083f3c45 in zend_hash_destroy ()
2  0x083e6fba in _zval_dtor_func ()
3  0x083da69a in _zval_dtor ()
4  0x083db3df in _zval_ptr_dtor ()
5  0x083f3c45 in zend_hash_destroy ()
6  0x083e6fba in _zval_dtor_func ()
7  0x083da69a in _zval_dtor ()
8  0x083db3df in _zval_ptr_dtor ()
9  0x083f3c45 in zend_hash_destroy ()
10 0x08406091 in zend_object_std_dtor ()
11 0x0840632e in zend_objects_free_object_storage ()
12 0x0840a44c in zend_objects_store_del_ref_by_handle_ex ()
13 0x0840a23b in zend_objects_store_del_ref ()
14 0x083e6fe1 in _zval_dtor_func ()
15 0x083da69a in _zval_dtor ()
16 0x083db3df in _zval_ptr_dtor ()
17 0x083f3c45 in zend_hash_destroy ()
18 0x08406091 in zend_object_std_dtor ()
19 0x0840632e in zend_objects_free_object_storage ()
20 0x0840a44c in zend_objects_store_del_ref_by_handle_ex ()
21 0x0840a23b in zend_objects_store_del_ref ()
22 0x083e6fe1 in _zval_dtor_func ()
23 0x083da69a in _zval_dtor ()
24 0x083db3df in _zval_ptr_dtor ()
25 0x083f3c45 in zend_hash_destroy ()
26 0x083e6fba in _zval_dtor_func ()
27 0x083da69a in _zval_dtor ()
28 0x083daed6 in shutdown_executor ()
29 0x083e86c8 in zend_deactivate ()
30 0x0838ebad in php_request_shutdown ()
31 0x084a3f26 in main ()

I'm using the memcache, apc, and mongo extensions (compiled from source). I tried disabling apc, but no luck. My PHP configure:

./configure \
    --prefix=/usr/local/php \
    --enable-fpm \
    --enable-inline-optimization \
    --disable-magic-quotes \
    --enable-mbstring \
    --enable-mbregex \
    --enable-safe-mode \
    --enable-wddx=shared \
    --enable-xml \
    --with-gd \
    --enable-gd-native-ttf \
    --with-png-dir=/usr \
    --with-jpeg-dir=/usr \
    --with-freetype-dir=/usr \
    --with-gettext \
    --with-curl \
    --with-mysql=/usr \
    --with-mysqli=/usr/bin/mysql_config \
    --with-regex=system \
    --with-zlib-dir=/usr/lib \
    --with-openssl \
    --with-snmp \
    --enable-ucd-snmp-hack

This happens only on one certain page of an application (code is too big to share). Looks like it's failing on shutdown. I saw this bug report on the PHP tracker from about 6 or 7 years ago, but haven't heard of anyone seeing it since.

What's weird is that everything was working fine a few days ago until I deployed some changes to the app. It was nothing monolithic, and I wish I could pinpoint the exact commit, but there were about 5 commits between when it worked and the next time I realized it wasn't working.

Can anyone make heads or tails of this, or should I submit a bug report and hope for the best?

Answer 1

You might be hit by https://bugs.php.net/bug.php?id=63055 "Segfault in zend_gc with SF2 testsuite" which apparently is caused by "any usage of zval_dtor with recursive array may trigger this segfault."

Answer 2

I have a client who is experiencing an almost identical coredump. They are using PHP 5.2.17 so this is a long-standing bug. Thank you for pointing out that snapshot that worked. I just extracted from PHP's svn as of that date and time and did a diff versus the stock 5.3.6. I suspect it was one of these that fixed it:

. Fixed bug #54585 (track_errors causes segfault).

. Fixed bug #54372 (Crash accessing global object itself returned from its __get() handle).

. Fixed bug #54262 (Crash when assigning value to a dimension in a non-array).

. Fixed a crash inside dtor for error handling.

. Fixed bug #54580 (get_browser() segmentation fault when browscap ini directive is set through php_admin_value).

You said this problem appeared between about 5 commits. Is there any chance you can provide me with a diff of your app containing just those 5 commits so we can figure out exactly which of the above fixes is the relevant one? It may help to determine a way around the bug.

Please feel free to email releaze3 AT gmail DOT com. Not my real email but I will respond from my real one (avoiding spam - I dont care if spam goes to that address). Hopefully together we can work out exactly what causes this and give people a work-around who can't upgrade their PHP.

Answer 3

Figured it out (sort of). Got the latest dev build (5.3-201105190430) from http://snaps.php.net/ and compiled & installed it. That fixed the problem (so apparently they know about it and have it queued for inclusion).

Thanks!