Bug #65590 [Com]: Apache segfaults and reports zend_mm_heap corrupted

From: Date: Wed, 16 Oct 2013 10:40:56 +0000
Subject: Bug #65590 [Com]: Apache segfaults and reports zend_mm_heap corrupted
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-182311@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=65590&edit=1

 ID:                 65590
 Comment by:         arjen at react dot com
 Reported by:        ole dot skudsvik at gmail dot com
 Summary:            Apache segfaults and reports zend_mm_heap corrupted
 Status:             Open
 Type:               Bug
 Package:            opcache
 Operating System:   Linux, CentOS 6
 PHP Version:        5.4.19
 Block user comment: N
 Private report:     N

 New Comment:

Looks like this also happens under php-fpm (5.5.4):

#0  0x000000000060dff7 in ?? ()
#1  0x000000000060e1fb in ?? ()
#2  0x0000000000642f2e in zend_hash_destroy ()
#3  0x0000000000625bc3 in ?? ()
#4  0x0000000000635412 in ?? ()
#5  0x00000000005d5c1d in php_request_shutdown ()
#6  0x0000000000426724 in ?? ()
#7  0x00007f406e548bc5 in __libc_start_main () from /usr/lib/libc.so.6
#8  0x0000000000427505 in _start ()


Previous Comments:
------------------------------------------------------------------------
[2013-09-09 10:24:38] ole dot skudsvik at gmail dot com

What i've found is that if you disable opcache.fast_shutdown in php.ini we do 
not experience any crashes.

The documentation of opcache.fast_shutdown states:

If enabled, a fast shutdown sequence is used for the accelerated code
The fast shutdown sequence doesn't free each allocated block, but lets
the Zend Engine Memory Manager do the work.

I've im also now able to reproduce the segfault by doing the following:

<?php
  opcache_reset(); 
  Zend\Mvc\Application::init(blah).run();
?>
What i think happen here is:

* We call opcache_reset() which triggers a free() on all opcache allocated 
resources.

* We start the Zend application.

* When the Zend application shuts down Zend tries to free the already free'ed 
memory since it's told to do so by the fast_shutdown flag.

Ofcourse Zend should check if the memory is already free'd before trying to free 
it, but it seems it does not ?

------------------------------------------------------------------------
[2013-08-30 09:01:29] ole dot skudsvik at gmail dot com

Description:
------------
We are experiencing regular Apache segfaults.

We are sadly not able to reproduce as this seems to happen randomly when apache 
have been running for a while. Neither can we relate the problem to any spesific 
PHP code.

Apache error.log:

[Wed Aug 28 13:00:50 2013] [notice] child pid 31638 exit signal Segmentation 
fault (11)
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
[Wed Aug 28 13:43:58 2013] [notice] child pid 13750 exit signal Segmentation 
fault (11)


GDB Backtrace:

Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
#0  zend_mm_add_to_free_list (heap=<value optimized out>, 
mm_block=0x7f8e9aef8cc0) at /usr/src/debug/php-5.4.19/Zend/zend_alloc.c:748
748  				if (ZEND_MM_FREE_BLOCK_SIZE(prev) != size) {
(gdb) bt
#0  zend_mm_add_to_free_list (heap=<value optimized out>, 
mm_block=0x7f8e9aef8cc0) at /usr/src/debug/php-5.4.19/Zend/zend_alloc.c:748
#1  0x00007f8e8ed74412 in _zend_mm_free_int (heap=0x7f8e9a32d6a0, 
p=0x7f8e9aef8cd0) at /usr/src/debug/php-5.4.19/Zend/zend_alloc.c:2114
#2  0x00007f8e8eda6ad1 in zend_hash_destroy (ht=0x7f8e8f19ffd0) at 
/usr/src/debug/php-5.4.19/Zend/zend_hash.c:565
#3  0x00007f8e8ed8d173 in shutdown_executor () at /usr/src/debug/php-
5.4.19/Zend/zend_execute_API.c:322
#4  0x00007f8e8ed99e52 in zend_deactivate () at /usr/src/debug/php-
5.4.19/Zend/zend.c:938
#5  0x00007f8e8ed3c67c in php_request_shutdown (dummy=<value optimized out>) at 
/usr/src/debug/php-5.4.19/main/main.c:1803
#6  0x00007f8e8ee44037 in php_apache_request_dtor (r=0x7f8e9ac8d1a8) at 
/usr/src/debug/php-5.4.19/sapi/apache2handler/sapi_apache2.c:507
#7  php_handler (r=0x7f8e9ac8d1a8) at /usr/src/debug/php-
5.4.19/sapi/apache2handler/sapi_apache2.c:679
#8  0x00007f8e97ea0bb0 in ap_run_handler (r=0x7f8e9ac8d1a8) at 
/usr/src/debug/httpd-2.2.15/server/config.c:158
#9  0x00007f8e97ea446e in ap_invoke_handler (r=0x7f8e9ac8d1a8) at 
/usr/src/debug/httpd-2.2.15/server/config.c:376
#10 0x00007f8e97eafb30 in ap_process_request (r=0x7f8e9ac8d1a8) at 
/usr/src/debug/httpd-2.2.15/modules/http/http_request.c:282
#11 0x00007f8e97eac9a8 in ap_process_http_connection (c=0x7f8e9ac80c18) at 
/usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
#12 0x00007f8e97ea86b8 in ap_run_process_connection (c=0x7f8e9ac80c18) at 
/usr/src/debug/httpd-2.2.15/server/connection.c:43
#13 0x00007f8e97eb4977 in child_main (child_num_arg=<value optimized out>) at 
/usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:667
#14 0x00007f8e97eb4c8a in make_child (s=0x7f8e99ffe860, slot=6) at 
/usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:763
#15 0x00007f8e97eb590c in perform_idle_server_maintenance (_pconf=<value 
optimized out>, plog=<value optimized out>, s=<value optimized out>) at 
/usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:898
#16 ap_mpm_run (_pconf=<value optimized out>, plog=<value optimized out>, 
s=<value optimized out>) at /usr/src/debug/httpd-
2.2.15/server/mpm/prefork/prefork.c:1102
#17 0x00007f8e97e8c900 in main (argc=1, argv=0x7fffb01ca148) at 
/usr/src/debug/httpd-2.2.15/server/main.c:760

A complete strace of the crash is available here: 
https://gist.github.com/olesku/6387821

Test script:
---------------
Currently not able to reproduce.



------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65590&edit=1


Thread (11 messages)

« previous php.bugs (#182311) next »