php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58123 zend_mm_heap corrupted
Submitted: 2008-03-27 01:58 UTC Modified: 2009-03-22 19:36 UTC
From: mjh at hodginsmedia dot com Assigned: gopalv (profile)
Status: Closed Package: APC (PECL)
PHP Version: 5.2.5 OS: RHEL5, AMD64
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:
Package:
Bug Type:
Summary:
From: mjh at hodginsmedia dot com
New email:
PHP Version: OS:

 

 [2008-03-27 01:58 UTC] mjh at hodginsmedia dot com
Description:
------------
Upgraded from APC 3.0.16 to 3.0.17.  Running Apache 2.2.3 on RHEL5.  Errors begin to appear in /var/log/httpd/error_log:

zend_mm_heap corrupted
zend_mm_heap corrupted

(and some PHP pages load blank)

Despite an identical bug name, this is probably NOT related to Bug#12695 because it does not seem to be isolated to pages handling file uploads.  Same error message in the logs, though...

Reproduce code:
---------------
INSTALL:
========
phpize
./configure --enable-apc --enable-apc-mmap --with-apxs --with-php-config=/usr/bin/php-config
make
make install

RESTART HTTPD:
==============
Restart httpd service (Apache 2.2.3 on RHEL5) and errors begin to appear in /var/log/httpd/error_log:

zend_mm_heap corrupted

(and some PHP pages load blank, others continue to load fine).

APC.INI
=======

extension=apc.so
[APC]
apc.enabled = On
apc.ttl = 7200
apc.user_ttl = 7200
apc.shm_segments = 1
apc.shm_size = 1024
apc.num_files_hint = 2048
apc.mmap_file_mask=/tmp/apc.XXXXXX

(note that I have tested with and without the mmap_file_mask setting - it makes no difference)

Expected result:
----------------
Stable httpd+php+apc

Actual result:
--------------
Repeated "zend_mm_heap corrupted" messages in /var/log/httpd/error_log and PHP pages load blank.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-03-27 06:51 UTC] daniz at rocketmail dot com
I can confirm this on my update from .16 -> .17. 
The errors are constant on my phpMyAdmin page. The lower part (where you create a new table) dosn't show (which I guess is where it gets the zend_mm_heap error) Other things on my page works luckily but it is indeed an annoying bug.

server: Litespeed 3.3.9 php 5.2.5 (also tried 5.2.6RC2 with same results)
 [2008-03-27 09:39 UTC] js100 at netpark dot us
Same problem experienced on Gentoo with source builds of Apache 2.2.8, PHP 5.2.5, and APC 3.0.17.  These are not the Gentoo sources but rather the official sources from the respective projects.

Problem can be duplicated with <?php phpinfo() ?>
 [2008-03-27 09:43 UTC] rggonzalez_dc at yahoo dot com
I can confirm this too: upgraded from .16 to .17 and got

[Thu Mar 27 08:34:59 2008] [notice] child pid 4047 exit signal Segmentation fault (11)
zend_mm_heap corrupted

on certain but not all scripts. This sometimes causes a zero sized reply send to the client. Using Slack 11 with Apache/2.2.8 (Unix) mod_ssl/2.2.8 OpenSSL/0.9.8d PHP/5.2.5

Configured:

CFLAGS="-O2 -mtune=nocona -mmmx -msse -msse2 -msse3" ./configure --with-php-config=/usr/local/bin/php-config

php.ini:

[APC]
extension=apc.so
apc.enabled=1
apc.shm_segments=1
apc.optimization=0
apc.shm_size=256
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.mmap_file_mask=/var/tmp/apc/apc.XXXXXX
apc.enable_cli=1
apc.slam_defense=80
 [2008-03-27 09:51 UTC] gopalv82 at yahoo dot com
Is everyone on AMD64?
 [2008-03-27 11:37 UTC] daniz at rocketmail dot com
Nope, Intel xeon quad here. Also 32bit all the way
 [2008-03-27 12:09 UTC] mad at wol dot de
Same problems here.
APC 3.0.17 / PHP 5.2.5 fastcgi / lighttpd 1.4.19

cacti's up to date index.php is also a good testcase.


configure used here: ./configure --enable-apc --enable-apc-futex

All on an glibc 2.7 / linux 2.6.24.4 i686 system
 [2008-03-27 15:10 UTC] rasmus@php.net
Everyone on PHP 5.2.5 perhaps?

www.php.net has been running 3.0.17 without a single problem for 48 hours now but it is running PHP 5.2.1.
 [2008-03-27 21:53 UTC] aturner at godaddy dot com
I'm running PHP 5.2.4/Fedora Core 7/Intel 32bit and PHP 5.2.3/FreeBSD/Intel 32bit and seeing the problems.
 [2008-03-28 03:06 UTC] skond66 at mail dot goo dot ne dot jp
CENTOS 4.6 kernel 2.6.9-67.0.7.ELsmp
Apache/2.0.52 PHP 4.3.9

At APC 3.0.17,these err occured. very many.server down.

(24)Too many open files: file permissions deny server access:

I back to APC 3.0.16. I hope to update or close quickly.
 [2008-03-28 03:38 UTC] tim at digicol dot de
Hi,

I have the same problem after updating from 3.0.16 to 3.0.17 
(most 
times blank pages in phpMyAdmin, especially in index.php, 
and the 
error message "zend_mm_heap corrupted").

I'm running PHP 5.2.5/Apache 2.2.3 on Debian 4.0 (32bit) 
under VMware, 
and phpMyAdmin is configured to use mysqli.

Switching back to 3.0.16 fixes the problem.
 [2008-03-28 09:02 UTC] gopalv82 at yahoo dot com
Mind testing, 

http://t3.dotgnu.info/code/apc-3.0.18-RC.patch

on top of 3.0.17?
 [2008-03-28 14:40 UTC] argiope at gmail dot com
Apache 2.2.8 
PHP 5.2.5 
APC 3.0.17
on FC6
I confirm the the bug as well.

[Fri Mar 28 15:33:50 2008] [notice] child pid 32271 exit signal Segmentation fault (11)

zend_mm_heap corrupted

[Fri Mar 28 15:34:22 2008] [notice] child pid 32272 exit signal Segmentation fault (11)
 [2008-03-28 16:00 UTC] rasmus@php.net
Fixed in 3.0.18
 [2009-02-11 17:27 UTC] aford at ign dot com
Sorry to post in such an old ticket, but is it possible something was reintroduced into 3.0.19, or maybe not entirely fixed since changes introduced in 3.0.17?

I have a large application that runs perfectly happy on php 5.2.2 with apc 3.0.16. But run that same app on php 5.2.6 and apc 3.0.19 and I'm getting "zend_mm_heap corrupted" in my apache error logs. I also experience empty http responses (blank pages) at times too, like others have reported.

Some more info if it helps. With apc.stat=0 I get the empty http responses but absolutely nothing in my apache or php error logs. Only when I turned apc.stat=1 did I start seeing the zend mm heap errors in the apache log.
 [2009-02-16 19:43 UTC] shire@php.net
Does this reproduce on the latest 3.1.2 release?
 [2009-03-20 23:35 UTC] aford at ign dot com
Well, I'm happy, and also sorry to say, this was a problem with my application. This is obviously not the first, and definitely not the last time someone reports a bug to Rasmus that turns out to be app related ;)

Anyway, our app was being used by a couple different web sites, each with their own unique include paths, and each needing to include some different model class files. So, at the top of the super controller used by both sites we included these model files, for example, the top of the controller looked like:

include 'model_a.php'; // This file only exists under site #1 include path
include 'model_b.php'; // This file only exists under site #1 include path
include 'model_c.php'; // This file only exists under site #1 include path

include 'model_d.php'; // This file only exists under site #2 include path
include 'model_e.php'; // This file only exists under site #2 include path
include 'model_f.php'; // This file only exists under site #2 include path

So, with apc stat=0 this is a problem. Let's say I clear the apc cache, and then I visit site #1 first. The super controller gets cached in apc, with the first 3 includes intact, and the last 3 ignored, because they were not in site #1's include_path. So now, you try to go to site #2, but you run into issues because those site #2 includes aren't cached with the super controller, but of course the classes are used later on.

So, that is a very simplified explanation, but it might help others. Basically, if you have shared app and/or lib files that need to include special case files for individual websites, you either have to dynamically include the files, like:

include SITE_INCLUDE_DIR.'models/model_a.php'; // SITE_INCLUDE_DIR is a constant that defines a site specific application directory like /www/app

Or, you'll need to include these files in a file that is also unique to the site, like the site's bootstrap for instance.

I think we're gonna take the dynamic include approach. Even though Rasmus has explained in the past that there is a slight performance hit because the class def has to be dynamically defined at execution time, the convenience in our apps is worth it I think. And, considering we use a front controller that already dynamically includes action controllers, we already have a little of that going on. Of course both are avoidable, but not very code maintainable friendly.
 [2009-03-20 23:37 UTC] aford at ign dot com
Oh, and just to clarify, my assumption that this was not an issue under apc 3.0.16 was wrong. I just happened to migrate some sites from a server farm running 3.0.16 to a newer server farm running 3.0.19. Of course, now I had more than one site on the same farm, and so the problem reared its head. It was easy to assume that the old farm was fine and the problem was with apc 3.0.19, but alas and of course, this shows up in 3.0.16 or 3.0.19.
 [2009-03-22 19:36 UTC] shire@php.net
You shouldn't be able to get zend_mm_heap corruption, even with incorrect PHP code.  If you're still getting these errors and can give us a reproduction on the latest CVS version we could investigate further.  If, however, you are experiencing incorrect output due to include dependencies then it sounds like this can stay closed.  Thanks!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 08:01:28 2024 UTC