Description:
------------
We are observing php5-fom segfaults on our systems after a script is terminated after reaching the max_execution_time limit (10s in our case). gdb gives the following stacktrace:

(gdb) bt
#0  0x000000000070cea9 in gc_zval_possible_root (zv=0x2cbf888) at /build/php5-pO28mL/php5-5.5.9+dfsg/Zend/zend_gc.c:143
#1  0x000000000070fdd7 in zend_object_std_dtor (object=0x2a05b98) at /build/php5-pO28mL/php5-5.5.9+dfsg/Zend/zend_objects.c:54
#2  0x000000000070fe09 in zend_objects_free_object_storage (object=0x2a05b98) at /build/php5-pO28mL/php5-5.5.9+dfsg/Zend/zend_objects.c:137
#3  0x0000000000715807 in zend_objects_store_free_object_storage (objects=objects@entry=0xcc9540 <executor_globals+928>) at /build/php5-pO28mL/php5-5.5.9+dfsg/Zend/zend_objects_API.c:97
#4  0x00000000006de433 in shutdown_executor () at /build/php5-pO28mL/php5-5.5.9+dfsg/Zend/zend_execute_API.c:293
#5  0x00000000006edc02 in zend_deactivate () at /build/php5-pO28mL/php5-5.5.9+dfsg/Zend/zend.c:935
#6  0x000000000068df9d in php_request_shutdown (dummy=dummy@entry=0x0) at /build/php5-pO28mL/php5-5.5.9+dfsg/main/main.c:1808
#7  0x00000000004634d4 in main (argc=<optimized out>, argv=<optimized out>) at /build/php5-pO28mL/php5-5.5.9+dfsg/sapi/fpm/fpm/fpm_main.c:1961

(We are actually running PHP 5.5.9, but this bug happens with all versions of the 5.5 branch.)

My suspicion to what happens: Our workload here is constructing and analyzing a recursive data structure, basically a complex tree. As this process can take a longer time, the script runs into the timeout and is killed by the PHP engine, leaving a half-constructed tree. The request out buffer of FPM shows that a timeout actually occurred:

(gdb) frame 7
#7  0x00000000004634d4 in main (argc=<optimized out>, argv=<optimized out>) at /build/php5-pO28mL/php5-5.5.9+dfsg/sapi/fpm/fpm/fpm_main.c:1961
1961	/build/php5-pO28mL/php5-5.5.9+dfsg/sapi/fpm/fpm/fpm_main.c: No such file or directory.
(gdb) print request
$2 = {listen_socket = 0, fd = 5, id = 1, keep = 0, closed = 0, in_len = 0, in_pad = 0, out_hdr = 0x7ffc1eac3630, 
  out_pos = 0x7ffc1eac387f "\216\031\241\220b\246\217\241\276"..., 
  out_buf = "\001\a\000\001\000\265\003\000PHP message: PHP Fatal error:  Maximum execution time of 10 seconds exceeded in "..., reserved = '\000' <repeats 15 times>, env = 0x7ffb58290040}

FPM then tries to clean up after the request, which involves freeing all the memory allocated for the objects created by the script. Due to the recursive nature of the tree and the circumstance that it's not fully constructed, the GC fails to properly walk along the object graph and crashes somewhere in the middle.

I can see that at the time of the crash, the object being cleaned up is part of our tree structure. I can also see that for some reason this object has already been cleaned up, and the engine is trying to clean it up again (refcount is -1 in unsigned int):

(gdb) frame 0
#0  0x000000000070cea9 in gc_zval_possible_root (zv=0x2cbf888) at /build/php5-pO28mL/php5-5.5.9+dfsg/Zend/zend_gc.c:143
143	in /build/php5-pO28mL/php5-5.5.9+dfsg/Zend/zend_gc.c
(gdb) print *zv
$1 = {value = {lval = 56754808, dval = 2,8040600869115946e-316, str = {val = 0x3620278 "0", len = 53482552}, ht = 0x3620278, obj = {handle = 56754808, handlers = 0x3301438}}, refcount__gc = 4294967295, type = 5 '\005', 
  is_ref__gc = 0 '\000'}

Any ideas what could be the issue here? Sadly upgrading to for example PHP7 is not currently an option for us, as there are many incompatibilities in our system.

Likely related to this report: https://bugs.php.net/bug.php?id=64111