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

go to bug id or search bugs for

Bug #54491 Crash during shutdown sequence
Submitted: 2011-04-08 05:27 UTC Modified: 2013-02-18 00:34 UTC
Votes:6
Avg. Score:5.0 ± 0.0
Reproduced:6 of 6 (100.0%)
Same Version:6 (100.0%)
Same OS:2 (33.3%)
From: msamson at chowly dot com Assigned:
Status: No Feedback Package: Reproducible crash
PHP Version: 5.3.6 OS: Fedora 14 x64
Private report: No CVE-ID: None
View Developer Edit
 [2011-04-08 05:27 UTC] msamson at chowly dot com 
Description:
------------
PHP crash either as a httpd module or as cli with `zend_mm_heap corrupted`.

Please see https://bugzilla.redhat.com/show_bug.cgi?id=694630

This was initially thought as a fedora packaging bug, but even a compiled from 
source php is producing the same error.


Test script:
---------------
Please see https://bugzilla.redhat.com/show_bug.cgi?id=694630 for a simple script.




Actual result:
--------------
Tested is using a 2 different virtual machines both running Fedora 14 x64. One 
with php from yum, the other compiled.

gdb reports no backtrace and says there is `no stack`.

Apache 2.2 crashes, running php-cli too.

relevant strace output:

  array(0) {
  }
}
		</div>
	</div>
</body>
</html>) = 1681
write(2, "zend_mm_heap corrupted\n", 23zend_mm_heap corrupted
) = 23
exit_group(1)                           = ?

Another one with sessions:
pwrite(3, "cart|a:1:{s:2:\"id\";C:7:\"MongoId\""..., 63, 0) = 63
close(3)                                = 0
close(4)                                = 0
write(2, "zend_mm_heap corrupted\n", 23zend_mm_heap corrupted
) = 23
exit_group(1)


It appears php is crashing at the end of the request just before delivering the 
content, when a database of some sort is used.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-04-08 06:28 UTC] msamson at chowly dot com 
Finally got a backtrace:
/Zend/Zend_execute_API.c:437
437 Z_DELREF_PP(zval_ptr);

There is a mention in another frame about requesting php shutdown. Then higher, it says it will cleanup a closure. Sadly, no execute and 
zbacktrace output was empty.
 [2011-04-08 09:54 UTC] aharvey@php.net
-Status: Open +Status: Feedback
 [2011-04-08 09:54 UTC] aharvey@php.net 
Does PHP only crash when the mongo extension is loaded? If so, please report this at http://pecl.php.net/package/mongo, as bugs in PECL extensions aren't dealt with in this bug tracker.
 [2011-04-08 17:05 UTC] msamson at chowly dot com
-Summary: Crash when using mongodb or couchdb database adapters +Summary: Crash during shutdown sequence on apache module. -Status: Feedback +Status: Open
 [2011-04-08 17:05 UTC] msamson at chowly dot com 
No, the crash also occurs when the mongo.so extension is not loaded.

At first, it thought it was the culprit, but it happens without mongo being 
loaded.

One thing, the CLI version seems to be more resilient, it needs more data loaded 
to crash, whereas with the apache module, it's always crashing.

Chromium reports `Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error` when 
accessing a url.

I was able to get a backtrace (with no execute or zbacktrace output) and around 
frame 30-ish, it specifies entering the shutdown sequence, cleaning up a closure 
and then the crash.

Changing the summary to better reflect the problem.
 [2011-04-08 17:50 UTC] msamson at chowly dot com
-Summary: Crash during shutdown sequence on apache module. +Summary: Crash during shutdown sequence
 [2011-04-08 17:50 UTC] msamson at chowly dot com 
Valgrind output of `php webroot/index.php`

</body>
</html>zend_mm_heap corrupted
==3214== 
==3214== HEAP SUMMARY:
==3214==     in use at exit: 7,084,078 bytes in 14,840 blocks
==3214==   total heap usage: 16,202 allocs, 1,362 frees, 7,502,798 bytes 
allocated
==3214== 
==3214== LEAK SUMMARY:
==3214==    definitely lost: 0 bytes in 0 blocks
==3214==    indirectly lost: 0 bytes in 0 blocks
==3214==      possibly lost: 5,259,364 bytes in 1,386 blocks
==3214==    still reachable: 1,824,714 bytes in 13,454 blocks
==3214==         suppressed: 0 bytes in 0 blocks
==3214== Rerun with --leak-check=full to see details of leaked memory
==3214== 
==3214== For counts of detected and suppressed errors, rerun with: -v
==3214== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 42 from 8)
 [2011-04-11 22:24 UTC] msamson at chowly dot com 
Just reproduced the bug in Ubuntu 10.10 i386 with a php 5.3.6 ppa

For a total of 2 different computers (both F14 x64) and 4 virtual machines:
Fedora x64 RPM
Fedora x64 Source
Ubuntu x64 PPA
Ubuntu x86 PPA
 [2011-05-15 23:49 UTC] crrodriguez at opensuse dot org 
[2011-04-08 15:50 UTC] msamson at chowly dot com : Can you post the gdb backtrace 
or a reproduce script ? and script that requires a framework or a third party 
extension is NOT reproduce code.
 [2011-05-16 01:12 UTC] crrodriguez at opensuse dot org 
msamson at chowly dot com: I reproduced your script, though no crash at all.


./../sapi/cli/php -v                                     
PHP 5.3.7-dev (cli) (built: May 15 2011 18:44:44) (DEBUG)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

Are you totally sure you posted *all* reproduce instructions ?
 [2011-05-16 10:46 UTC] johannes@php.net
-Status: Open +Status: Feedback
 [2011-05-16 14:32 UTC] msamson at chowly dot com 
I will test with 5.3.7, but 5.3.5 works like a charm running the exact same code.
 [2013-02-18 00:34 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 "Open". Thank you.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Thu Jul 03 16:01:36 2025 UTC