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!