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.

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)

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() ?>

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

Is everyone on AMD64?

Nope, Intel xeon quad here. Also 32bit all the way

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

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.

I'm running PHP 5.2.4/Fedora Core 7/Intel 32bit and PHP
5.2.3/FreeBSD/Intel 32bit and seeing the problems.

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.

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.

Mind testing, 

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

on top of 3.0.17?

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)

Fixed in 3.0.18

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.

Does this reproduce on the latest 3.1.2 release?

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.

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.

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!