|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #71632 FPM segfaults in shutdown after max_execution_time reached
Submitted: 2016-02-19 16:26 UTC Modified: -
Avg. Score:4.0 ± 1.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:-1 (-100.0%)
From: thz at plista dot com Assigned:
Status: Open Package: FPM related
PHP Version: 5.5.32 OS: Linux
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.
Block user comment
Status: Assign to:
Bug Type:
From: thz at plista dot com
New email:
PHP Version: OS:


 [2016-02-19 16:26 UTC] thz at plista dot com
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:


Add a Patch

Pull Requests

Add a Pull Request

PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed Jan 27 08:01:26 2021 UTC