blocks|key|1331067|text|经过反复试验，我发现如果增加php.ini文件中的output_buffering值，这个错误就会消失|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1331068|entityMap^0|P|G|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

After much trial and error, I found that if I increase the <code>output_buffering</code> value in the php.ini file, this error goes away

blocks|key|1331419|text|如果您使用的是Linux+box，请在命令行中尝试执行以下操作|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331420|export+USE_ZEND_ALLOC=0|code-block|syntax|javascript|1331421|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

If you are on Linux box, try this on the command line 

<pre><code>export USE_ZEND_ALLOC=0
</code></pre>

blocks|key|1331369|text|检查unset()%25s。确保您没有在析构函数中unset()对$this+(或等效对象)的引用，并且析构函数中的unset()%25s不会导致对同一对象的引用计数降到0。我做了一些研究，发现这通常是导致堆损坏的原因。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1331370|出现PHP+bug+report+about+the+zend_mm_heap+corrupted错误。有关如何重现它的示例，请参阅comment+[2011-08-31+07:49+UTC]+f+dot+ardelian+at+gmail+dot+com。|1331371|我有一种感觉，所有其他的“解决方案”(改变php.ini，用更少的模块从源码编译PHP，等等)只需隐藏问题。|1331372|entityMap|0|LINK|mutability|MUTABLE|url|https://bugs.php.net/bug.php?id=40479^0|2|7|N|7|V|5|1K|7|0|22|1I|2|1B|0|0|L|7|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@$9|13|A|14|1|15]]|E|$]]|$1|H|3|I|5|6|7|16|8|@$9|17|A|18|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

Check for <code>unset()</code>s. Make sure you don't <code>unset()</code> references to the <code>$this</code> (or equivalents) in destructors and that <code>unset()</code>s in destructors don't cause the reference count to the same object to drop to 0. I've done some research and found that's what usually causes the heap corruption.

There is a <a href="https://bugs.php.net/bug.php?id=40479">PHP bug report about the zend_mm_heap corrupted</a> error. See the comment <code>[2011-08-31 07:49 UTC] f dot ardelian at gmail dot com</code> for an example on how to reproduce it.

I have a feeling that all the other "solutions" (change <code>php.ini</code>, compile PHP from source with less modules, etc.) just hide the problem.

blocks|key|1117166|text|对我来说，之前的答案都不起作用，直到我尝试：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1117167|opcache.fast_shutdown=0|code-block|syntax|javascript|1117168|到目前为止，这似乎是可行的。|1117169|我正在使用PHP5.6与PHP-FPM和Apache+proxy_fcgi，如果这很重要的话...|1117170|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

For me none of the previous answers worked, until I tried:

<pre><code>opcache.fast_shutdown=0
</code></pre>

That seems to work so far. 

I'm using PHP 5.6 with PHP-FPM and Apache proxy_fcgi, if that matters...

blocks|key|1331483|text|在我的例子中，这个错误的原因是其中一个数组变得非常大。我已经将我的脚本设置为在每次迭代时重置数组，这解决了问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331484|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In my case, the cause for this error was one of the arrays was becoming very big. I've set my script to reset the array on every iteration and that sorted the problem.

blocks|key|1117210|text|根据错误跟踪器，设置opcache.fast_shutdown=0。Fast+shutdown使用Zend内存管理器来清理它的混乱，这会禁用它。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1117211|entityMap^0|A|N|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

As per the bug tracker, set <code>opcache.fast_shutdown=0</code>. Fast shutdown uses the Zend memory manager to clean up its mess, this disables that.

blocks|key|1331181|text|我与这个问题搏斗了一个星期，这对我很有效，至少看起来是这样。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331182|在php.ini中进行以下更改|offset|length|style|CODE|1331183|report_memleaks+=+Off++
report_zend_debug+=+0++|code-block|syntax|javascript|1331184|我的设置是|1331185|Linux+ubuntu+2.6.32-30-generic-pae+#59-Ubuntu+SMP++
with+PHP+Version+5.3.2-1ubuntu4.7++|1331186|这不管用。|1331187|因此，我尝试使用基准测试脚本，并尝试记录脚本挂起的位置。我发现就在出现错误之前，一个php对象被实例化了，它花了超过3秒的时间来完成这个对象应该做的事情，而在前面的循环中，它最多花了0.4秒。我多次运行这个测试，每次都是一样的。我想，与其每次都创建一个新对象(这里有一个很长的循环)，不如重用这个对象。到目前为止，我已经测试了这个脚本十几次，内存错误已经消失了！|1331188|entityMap^0|0|1|7|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@$D|Y|E|Z|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|10|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

I wrestled with this issue, for a week, This worked for me, or atleast so it seems 

In <code>php.ini</code> make these changes 

<pre><code>report_memleaks = Off 
report_zend_debug = 0 
</code></pre>

My set up is 

<pre><code>Linux ubuntu 2.6.32-30-generic-pae #59-Ubuntu SMP 
with PHP Version 5.3.2-1ubuntu4.7 
</code></pre>

This didn’t work. 

So I tried using a benchmark script, and tried recording where the script was hanging up.
I discovered that just before the error, a php object was instantiated, and it took more than 3 seconds to complete what the object was supposed to do, whereas in the previous loops it took max 0.4 seconds. I ran this test quite a few times, and every time the same. I thought instead of making a new object every time, (there is a long loop here), I should reuse the object. I have tested the script more than a dozen times so far, and the memory errors have disappeared!

blocks|key|1116076|text|查找任何使用缓冲的模块，并有选择地禁用它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1116077|我在CentOS+4.8上运行PHP5.3.5，之后我发现eaccelerator需要升级。|1116078|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Look for any module that uses buffering, and selectively disable it.

I'm running PHP 5.3.5 on CentOS 4.8, and after doing this I found eaccelerator needed an upgrade.

blocks|key|1331290|text|我刚刚在我自己的服务器上也遇到了这个问题，根本原因是APC。我注释掉了php.ini文件中的"apc.so“扩展名，重新加载了Apache，站点马上就恢复了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331291|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I just had this issue as well on a server I own, and the root cause was APC. I commented out the "apc.so" extension in the php.ini file, reloaded Apache, and the sites came right back up.

blocks|key|1116506|text|我已经尝试了上面的所有方法和zend.enable_gc+=+0+-唯一对我有帮助的配置设置。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1116507|PHP+5.3.10-1ubuntu3.2带Suhosin-Patch+(cli)+(built:+Jun+13+2012+17:19:58)|1116508|entityMap^0|E|I|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

I've tried everything above and <code>zend.enable_gc = 0</code> - the only config setting, that helped me.

PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) (built: Jun 13 2012 17:19:58)

blocks|key|1331688|text|我在使用PHP的Mongo+2.2驱动程序时遇到了这个错误：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331689|$collection+=+$db->selectCollection('post');
$collection->ensureIndex(array('someField',+'someOtherField',+'yetAnotherField'));+|code-block|syntax|javascript|1331690|%5E%5E不工作|1331691|$collection+=+$db->selectCollection('post');
$collection->ensureIndex(array('someField',+'someOtherField'));+
$collection->ensureIndex(array('yetAnotherField'));+|1331692|%5E%5E有效！(?!)|1331693|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I had this error using the Mongo 2.2 driver for PHP:

<pre><code>$collection = $db-&gt;selectCollection('post');
$collection-&gt;ensureIndex(array('someField', 'someOtherField', 'yetAnotherField')); 
</code></pre>

^^DOESN'T WORK

<pre><code>$collection = $db-&gt;selectCollection('post');
$collection-&gt;ensureIndex(array('someField', 'someOtherField')); 
$collection-&gt;ensureIndex(array('yetAnotherField')); 
</code></pre>

^^ WORKS! (?!)

blocks|key|1331743|text|在PHP+5.3上，经过大量的搜索，这是对我有效的解决方案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331744|我通过添加以下内容对此页面执行了disabled+the+PHP+garbage+collection：|offset|length|1331745|<?+gc_disable();+?>|code-block|syntax|javascript|1331746|到有问题的页面的结尾，这使得所有的错误都消失了。|1331747|source。|1331748|entityMap|0|LINK|mutability|MUTABLE|url|http://php.net/manual/en/function.gc-disable.php|1|https://bugs.php.net/bug.php?id=40479^0|0|G|Z|0|0|0|0|0|6|1|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@$D|10|E|11|1|12]]|A|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|15|8|@]|9|@$D|16|E|17|1|18]]|A|$]]|$1|O|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]|W|$5|R|S|T|A|$U|X]]]]

On PHP 5.3 , after lot's of searching, this is the solution that worked for me:

I've <a href="http://php.net/manual/en/function.gc-disable.php" rel="nofollow">disabled the PHP garbage collection</a> for this page by adding:

<pre><code>&lt;? gc_disable(); ?&gt;
</code></pre>

to the end of the problematic page, that made all the errors disappear. 

<a href="https://bugs.php.net/bug.php?id=40479" rel="nofollow">source</a>.

blocks|key|1116869|text|我认为有很多原因会导致这个问题。在我的例子中，我将两个类命名为相同的名称，一个类将尝试加载另一个类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1116870|class+A+{}+//+in+file+a.php
class+A+//+in+file+b.php
{
++public+function+foo()+{+//+load+a.php+}
}|code-block|syntax|javascript|1116871|在我的例子中，它导致了这个问题。|1116872|(使用laravel框架，实际运行php+artisan+db:seed+)|1116873|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I think a lot of reason can cause this problem. And in my case, i name 2 classes the same name, and one will try to load another. 

<pre><code>class A {} // in file a.php
class A // in file b.php
{
 public function foo() { // load a.php }
}
</code></pre>

And it causes this problem in my case.

(Using laravel framework, running php artisan db:seed in real)

blocks|key|1116194|text|当我为memcached会话的session.save_path设置了错误的IP时，我也遇到了同样的问题。将其更改为正确的IP地址解决了此问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1116195|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I had this same issue and when I had an incorrect IP for session.save_path for memcached sessions. Changing it to the correct IP fixed the problem.

blocks|key|1331532|text|如果你正在使用特征，并且特征是在类之后加载的(即，自动加载的情况)，您需要预先加载特征。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331533|https://bugs.php.net/bug.php?id=62339|offset|length|1331534|注意:这个bug是非常随机的；由于它的性质。|1331535|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|11|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@$D|Q|E|R|1|S]]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]]]

If you are using traits and the trait is loaded after the class (ie. the case of autoloading) you need to load the trait beforehand.

<a href="https://bugs.php.net/bug.php?id=62339" rel="nofollow">https://bugs.php.net/bug.php?id=62339</a>

Note: this bug is very very random; due to it's nature.

blocks|key|1331558|text|对我来说，问题是使用pdo_mysql。查询返回1960个结果。我试着返回1900条记录，但它起作用了。所以问题是pdo_mysql和太大的数组。我用原始的mysql扩展重写了查询，它起作用了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331559|$link+=+mysql_connect('localhost',+'user',+'xxxx')+or+die(mysql_error());
mysql_select_db("db",+$link);|code-block|syntax|javascript|1331560|Apache没有报告任何以前的错误。|1331561|zend_mm_heap+corrupted
zend_mm_heap+corrupted
zend_mm_heap+corrupted
[Mon+Jul+30+09:23:49+2012]+[notice]+child+pid+8662+exit+signal+Segmentation+fault+(11)
[Mon+Jul+30+09:23:50+2012]+[notice]+child+pid+8663+exit+signal+Segmentation+fault+(11)
[Mon+Jul+30+09:23:54+2012]+[notice]+child+pid+8666+exit+signal+Segmentation+fault+(11)
[Mon+Jul+30+09:23:55+2012]+[notice]+child+pid+8670+exit+signal+Segmentation+fault+(11)|1331562|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

For me the problem was using pdo_mysql. Query returned 1960 results. I tried to return 1900 records and it works. So problem is pdo_mysql and too large array. I rewrote query with original mysql extension and it worked.

<pre><code>$link = mysql_connect('localhost', 'user', 'xxxx') or die(mysql_error());
mysql_select_db("db", $link);
</code></pre>

Apache did not report any previous errors. 

<pre><code>zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
[Mon Jul 30 09:23:49 2012] [notice] child pid 8662 exit signal Segmentation fault (11)
[Mon Jul 30 09:23:50 2012] [notice] child pid 8663 exit signal Segmentation fault (11)
[Mon Jul 30 09:23:54 2012] [notice] child pid 8666 exit signal Segmentation fault (11)
[Mon Jul 30 09:23:55 2012] [notice] child pid 8670 exit signal Segmentation fault (11)
</code></pre>

blocks|key|1331848|text|"zend_mm_heap损坏“表示内存管理出现问题。可以由任何PHP模块引起。在我的例子中，安装APC是可行的。从理论上讲，其他包，如eAccelerator，XDebug等也可能有所帮助。或者，如果您安装了这种类型的模块，请尝试将其关闭。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331849|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

"zend_mm_heap corrupted" means problems with memory management. Can be caused by any PHP module.
In my case installing APC worked out. In theory other packages like eAccelerator, XDebug etc. may help too. Or, if you have that kind of modules installed, try switching them off.

blocks|key|1116823|text|我正在写一个php扩展，也遇到了这个问题。当我从我的扩展中调用一个带有复杂参数的外部函数时，这个错误弹出。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1116824|原因是我没有为extern函数中的参数(char+*)分配内存。如果您正在编写相同类型的扩展，请注意这一点。|1116825|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I am writing a php extension and also encounter this problem. When i call an extern function with complicated parameters from my extension, this error pop up. 

The reason is my not allocating memory for a parameter(char *) in the extern function. If you are writing same kind of extension, please pay attention to this.

blocks|key|1117422|text|zend_mm_heap损坏的问题让我困惑了几个小时。首先，我禁用并删除了memcached，尝试了这个问题答案中提到的一些设置，在测试之后，这似乎是OPcache设置的问题。我禁用了OPcache，问题就消失了。之后，我重新启用了OPcache，对我来说|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1117423|core+notice:+child+pid+exit+signal+Segmentation+fault|code-block|syntax|javascript|1117424|和|1117425|zend_mm_heap+corrupted|1117426|显然是通过更改|1117427|/etc/php.d/10-opcache.ini|1117428|我在这里包含了我更改的设置；opcache.revalidate_freq=2仍然处于注释状态，我没有更改该值。|1117429|opcache.enable=1
opcache.enable_cli=0
opcache.fast_shutdown=0
opcache.memory_consumption=1024
opcache.interned_strings_buffer=128
opcache.max_accelerated_files=60000|1117430|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|11|8|@]|9|@]|A|$E|F]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

The issue with zend_mm_heap corrupted boggeld me for about a couple of hours. Firstly I disabled and removed memcached, tried some of the settings mentioned in this question's answers and after testing this seemed to be an issue with OPcache settings. I disabled OPcache and the problem went away. After that I re-enabled OPcache and for me the
<pre><code>core notice: child pid exit signal Segmentation fault
</code></pre>
and
<pre><code>zend_mm_heap corrupted
</code></pre>
are apparently resolved with changes to
<pre><code>/etc/php.d/10-opcache.ini
</code></pre>
I included the settings I changed here; opcache.revalidate_freq=2 remains commmented out, I did not change that value.
<pre><code>opcache.enable=1
opcache.enable_cli=0
opcache.fast_shutdown=0
opcache.memory_consumption=1024
opcache.interned_strings_buffer=128
opcache.max_accelerated_files=60000
</code></pre>

blocks|key|1330947|text|对我来说，是ZendDebugger导致了内存泄漏并导致MemoryManager崩溃。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1330948|我把它停用了，现在我正在寻找一个更新的版本。如果我找不到，我会切换到xdebug...|1330949|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

For me, it was the ZendDebugger that caused the memory leak and cuased the MemoryManager to crash.

I disabled it and I'm currently searching for a newer version. If I can't find one, I'm going to switch to xdebug...

blocks|key|1331021|text|因为我一直没有找到解决方案，所以我决定升级我的LAMP环境。我用PHP+5.3.x升级到了Ubuntu+10.4+LTS。这似乎为我解决了这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331022|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Because I never found a solution to this I decided to upgrade my LAMP environment. I went to Ubuntu 10.4 LTS with PHP 5.3.x. This seems to have stopped the problem for me.

blocks|key|1116439|text|设置|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1116440|assert.active+=+0+|code-block|syntax|javascript|1116441|在php.ini中对我有帮助(它关闭了php5UTF8库中的类型断言，zend_mm_heap+corrupted也消失了)|offset|length|style|CODE|1116442|entityMap^0|0|0|J|8|Z|M|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]|$I|T|J|U|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

Setting 

<pre><code>assert.active = 0 
</code></pre>

in php.ini helped for me (it turned off type assertions in <code>php5UTF8</code> library and <code>zend_mm_heap corrupted</code> went away)

blocks|key|1331652|text|在运行旧代码时，我也注意到了这个错误和SIGSEGV，旧代码在PHP+5.2%2B中运行时使用'&‘显式强制引用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331653|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I've also noticed this error and SIGSEGV's when running old code which uses '&amp;' to explicitly force references while running it in PHP 5.2+.

blocks|key|1331808|text|对我来说，问题在于memcached守护进程崩溃，因为PHP被配置为在memcached中存储会话信息。它消耗了100%25的cpu，而且表现得很奇怪。在memcached重启问题消失之后。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331809|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For me the problem was crashed memcached daemon, as PHP was configured to store session information in memcached. It was eating 100% cpu and acting weird. After memcached restart problem has gone.

blocks|key|1331979|text|由于其他答案都没有解决这个问题，所以我在php+5.4中遇到了这个问题，当时我意外地运行了一个无限循环。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1331980|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Since none of the other answers addressed it, I had this problem in php 5.4 when I accidentally ran an infinite loop.

blocks|key|1116967|text|一些可能对某人有帮助的小贴士|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1116968|fedora+20，php+5.5.18|1116969|public+function+testRead()+{
++++$ri+=+new+MediaItemReader(self::getMongoColl('Media'));

++++foreach+($ri->dataReader(10)+as+$data)+{
+++++++//+...
++++}
}

public+function+dataReader($numOfItems)+{
++++$cursor+=+$this->getStorage()->find()->limit($numOfItems);

++++//+here+is+the+first+place+where+"zend_mm_heap+corrupted"+error+occurred
++++//+var_dump()+inside+foreach-loop+and+generator
++++var_dump($cursor);+

++++foreach+($cursor+as+$data)+{
++++++++//+...
++++++++//+and+this+is+the+second+place+where+"zend_mm_heap+corrupted"+error+occurred
++++++++$data['Geo']+=+[
++++++++++++//+try+to+access+[0]+index+that+is+absent+in+['Geo']
++++++++++++'lon'+=>+$data['Geo'][0],
++++++++++++'lat'+=>+$data['Geo'][1]
++++++++];
++++++++//+...
++++++++//+Generator+is+used++!!!
++++++++yield+$data;
++++}
}|code-block|syntax|javascript|1116970|使用var_dummp()实际上并不是一个错误，它只是为了调试而放置的，并将在生产代码中删除。但真正发生zend_mm_heap的地方是第二个地方。|1116971|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Some of tips that may helps some one

fedora 20, php 5.5.18



<pre><code>public function testRead() {
 $ri = new MediaItemReader(self::getMongoColl('Media'));

 foreach ($ri-&gt;dataReader(10) as $data) {
 // ...
 }
}

public function dataReader($numOfItems) {
 $cursor = $this-&gt;getStorage()-&gt;find()-&gt;limit($numOfItems);

 // here is the first place where "zend_mm_heap corrupted" error occurred
 // var_dump() inside foreach-loop and generator
 var_dump($cursor); 

 foreach ($cursor as $data) {
 // ...
 // and this is the second place where "zend_mm_heap corrupted" error occurred
 $data['Geo'] = [
 // try to access [0] index that is absent in ['Geo']
 'lon' =&gt; $data['Geo'][0],
 'lat' =&gt; $data['Geo'][1]
 ];
 // ...
 // Generator is used !!!
 yield $data;
 }
}
</code></pre>

using var_dummp() actually not an error, it was placed just for debugging and will be removed on production code. But real place where zend_mm_heap was happened is the second place.

blocks|key|1117029|text|我在这里处于同样的情况，上面没有任何帮助，并且更认真地检查我发现了我的问题，它存在于尝试做模具(头())发送一些输出到缓冲区后，在代码中这样做的人忘记了重定向资源，并且没有简单地"return+$+CakePHP+->redirect($url)“。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1117030|试图重新发明油井，这就是问题所在。|1117031|希望这篇文章能对大家有所帮助！|1117032|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I was in same situation here, nothing above helped, and checking more seriously I find my problem, it consist in try do die(header()) after send some output to buffer, the man who did this in the Code forgot about CakePHP resources and did not made a simples "return $this->redirect($url)".

Trying to re-invent the well, this was the problem.

I hope this relate help someone!

blocks|key|1117109|text|对我来说，这是RabbitMq与Xdebug到PHPStorm，所以>设置/语言和框架/PHP/调试/Xdebug>+untick“可以接受外部连接”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1117110|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For me it was RabbitMq with Xdebug into PHPStorm, so > Settings/Language and frameworks/PHP/Debug/Xdebug > untick "Can accept external connections".

blocks|key|1332310|text|真正的在你的代码中寻找一个无声的错误。在我的Symfony应用程序中，我从一个树枝基础模板中删除了一个块，而没有记住它在子模板中被引用，因此我得到了zend_mm_heap损坏的错误。未抛出任何错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1332311|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Really hunt through your code for a silent error. In my Symfony app I got the zend_mm_heap corrupted error after removing a block from a twig base template not remembering it was referenced in sub templates. No error was thrown.

blocks|key|1117338|text|在升级到杰西的Debian服务器上安装了zend_mm_heap+corrupted和child+pid+...+exit+signal+Segmentation+fault。经过长时间的调查，发现XCache是在Zend-Engine普遍可用之前安装的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1117339|在apt-get+remove+php5-xcache和service+apache2+restart之后，错误消失了。|1117340|entityMap^0|K|M|17|18|0|1|Q|S|N|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|I|$]]

Had <code>zend_mm_heap corrupted</code> along with <code>child pid ... exit signal Segmentation fault</code> on a Debian server that was upgraded to jessie. After long investigation it turned out that XCache was installed prior Zend-Engine was generally available.

after <code>apt-get remove php5-xcache</code> and <code>service apache2 restart</code> the errors vanished.

blocks|key|1117493|text|在使用docker+&php内置开发服务器和Craft+CMS时，我在本地开发中遇到了这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1117494|我的解决方案是使用Redis进行Craft的会话。|1117495|PHP+7.4|1117496|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I experienced this issue in local development while using docker &amp; php's built in dev server with Craft CMS.
My solution was to use Redis for Craft's sessions.
PHP 7.4

All of the sudden I've been having problems with my application that I've never had before. I decided to check the Apache's error log, and I found an error message saying "zend_mm_heap corrupted". What does this mean.

OS: Fedora Core 8
Apache: 2.2.9
PHP: 5.2.6

What does "zend_mm_heap corrupted" mean

突然之间，我的应用程序出现了一些以前从未遇到过的问题。我决定检查Apache的错误日志，我发现了一条错误消息，上面写着"zend_mm_heap已损坏“。这是什么意思。操作系统: Fedora Core 8 Apache: 2.2.9 PHP: 5.2.6

问"zend_mm_heap损坏“是什么意思？
EN

回答 31

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问"zend_mm_heap损坏“是什么意思？EN

回答 31

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问"zend_mm_heap损坏“是什么意思？
EN