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

go to bug id or search bugs for

Bug #68749 random segmentation fault crashes
Submitted: 2015-01-05 12:18 UTC Modified: 2015-01-18 04:22 UTC
From: francesco at versiliaservices dot com Assigned:
Status: No Feedback Package: *General Issues
PHP Version: 5.6.4 OS: Centos 64bit
Private report: No CVE-ID: None
View Developer Edit
 [2015-01-05 12:18 UTC] francesco at versiliaservices dot com 
Description:
------------
we are experiencing ranodm segfaults crashes, with different scripts.
Therefore, unfortunately, we have no code to reproduce the crash.

PHP configuration (we're using php-fpm and latest nginx)

'./configure' '--prefix=/usr/local/php-krs-fpm' '--without-pear' '--without-sqlite3' '--without-pdo-sqlite' '--disable-phar' '--disable-fileinfo' '--with-gd' '--with-png-dir' '--with-jpeg-dir' '--with-freetype-dir' '--with-mysqli=mysqlnd' '--with-bz2' '--with-curl' '--enable-mbstring' '--enable-sockets' '--with-zlib' '--disable-simplexml' '--disable-pdo' '--disable-dom' '--enable-fpm' 



Actual result:
--------------
Program terminated with signal 11, Segmentation fault.
#0  zend_hash_clean (ht=0x7ffa46bda5b8) at /usr/src/php-5.6.4/Zend/zend_hash.c:582
582                     p = p->pListNext;

(gdb) bt
#0  zend_hash_clean (ht=0x7ffa46bda5b8) at /usr/src/php-5.6.4/Zend/zend_hash.c:582
#1  0x000000000066aa2b in zend_cleanup_op_array_data (function=<value optimized out>) at /usr/src/php-5.6.4/Zend/zend_opcode.c:134
#2  zend_cleanup_function_data (function=<value optimized out>) at /usr/src/php-5.6.4/Zend/zend_opcode.c:141
#3  0x00000000006823e3 in zend_hash_reverse_apply (ht=0x20c16a0, apply_func=0x66aa00 <zend_cleanup_function_data>) at /usr/src/php-5.6.4/Zend/zend_hash.c:729
#4  0x000000000066837b in shutdown_executor () at /usr/src/php-5.6.4/Zend/zend_execute_API.c:286
#5  0x0000000000675632 in zend_deactivate () at /usr/src/php-5.6.4/Zend/zend.c:963
#6  0x0000000000614efd in php_request_shutdown (dummy=<value optimized out>) at /usr/src/php-5.6.4/main/main.c:1884
#7  0x0000000000721479 in main (argc=<value optimized out>, argv=<value optimized out>) at /usr/src/php-5.6.4/sapi/fpm/fpm/fpm_main.c:1988

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-01-09 07:21 UTC] krakjoe@php.net
-Status: Open +Status: Feedback
 [2015-01-09 07:21 UTC] krakjoe@php.net 
There is not enough information to investigate the problem here. 

It is in your best interest to investigate the problem further and attempt to find a way to reproduce the bug.

This is the only way to move forward.
 [2015-01-18 04:22 UTC] php-bugs at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2017-04-03 04:32 UTC] majo-bugs dot php dot net at pematon dot com 
Same problem here. FreeBSD 11.0 with PHP 5.6.30 and Apache 2.4.25.

Program terminated with signal 10, Bus error.

#0  zend_hash_clean (ht=<value optimized out>) at zend_hash.c:584
#1  0x000000080563a2f6 in zend_cleanup_function_data (function=<value optimized out>) at zend_opcode.c:134
#2  0x0000000805652967 in zend_hash_reverse_apply (ht=<value optimized out>, apply_func=<value optimized out>) at zend_hash.c:729
#3  0x0000000805635ebf in shutdown_executor () at zend_execute_API.c:283
#4  0x000000080564598b in zend_deactivate () at zend.c:960
#5  0x00000008055e4ed6 in php_request_shutdown (dummy=<value optimized out>) at main.c:1899
#6  0x00000008056d3656 in php_handler (r=<value optimized out>) at sapi_apache2.c:507
#7  0x0000000000455b15 in ap_invoke_handler (r=<value optimized out>) at config.c:170
#8  0x000000000046bed6 in ap_internal_redirect (new_uri=<value optimized out>, r=<value optimized out>) at http_request.c:765
#9  0x000000080506fa10 in ?? () from /usr/local/libexec/apache24/mod_rewrite.so
#10 0x0000000000455b15 in ap_invoke_handler (r=<value optimized out>) at config.c:170
#11 0x000000000046b9f2 in ap_process_async_request (r=<value optimized out>) at http_request.c:436
#12 0x000000000046ba89 in ap_process_request (r=0x80d3e90a0) at http_request.c:471
#13 0x00000000004685d2 in ap_process_http_connection (c=<value optimized out>) at http_core.c:210
#14 0x0000000000460805 in ap_process_connection (c=<value optimized out>, csd=<value optimized out>) at connection.c:42
#15 0x0000000000473405 in child_main (child_num_arg=<value optimized out>, child_bucket=<value optimized out>) at prefork.c:723
#16 0x0000000000472efb in make_child (s=<value optimized out>, slot=<value optimized out>, bucket=<value optimized out>) at prefork.c:824
#17 0x0000000000472653 in prefork_run (_pconf=<value optimized out>, plog=<value optimized out>, s=<value optimized out>) at prefork.c:932
#18 0x000000000043890b in ap_run_mpm (pconf=<value optimized out>, plog=<value optimized out>, s=<value optimized out>) at mpm_common.c:94
#19 0x0000000000430e93 in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:783
 [2017-04-03 06:22 UTC] majo-bugs dot php dot net at pematon dot com 
The problem in our case was that one WordPress site started to consume to much memory and has been terminated:

    Allowed memory size of 268435456 bytes exhausted (tried to allocate 109 bytes)

That has probably left PHP in some unclean state causing other sites to return empty responses from server (no headers) and/or crash (we are using Apache's prefork mpm).

After increasing the memory limit the problem has been "solved".
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Oct 25 01:00:01 2025 UTC