De repente, he tenido problemas con mi aplicación que nunca antes había tenido. Decidí revisar el registro de errores de Apache, y encontré un mensaje de error que decía "zend_mm_heap dañado". Qué significa esto.

SO: Fedora Core 8 Apache: 2.2.9 PHP: 5.2.6

Después de mucho ensayo y error, descubrí que si aumento el output_bufferingvalor en el archivo php.ini, este error desaparece

Este no es un problema que necesariamente se puede resolver cambiando las opciones de configuración.

Cambiar las opciones de configuración a veces tendrá un impacto positivo, pero con la misma facilidad puede empeorar las cosas o no hacer nada.

La naturaleza del error es la siguiente:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(void) {
    void **mem = malloc(sizeof(char)*3);
    void *ptr;

    /* read past end */
    ptr = (char*) mem[5];   

    /* write past end */
    memcpy(mem[5], "whatever", sizeof("whatever"));

    /* free invalid pointer */
    free((void*) mem[3]);

    return 0;
}

El código anterior se puede compilar con:

gcc -g -o corrupt corrupt.c

Al ejecutar el código con valgrind, puede ver muchos errores de memoria, que culminan en un error de segmentación:

krakjoe@fiji:/usr/src/php-src$ valgrind ./corrupt
==9749== Memcheck, a memory error detector
==9749== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==9749== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==9749== Command: ./corrupt
==9749== 
==9749== Invalid read of size 8
==9749==    at 0x4005F7: main (an.c:10)
==9749==  Address 0x51fc068 is 24 bytes after a block of size 16 in arena "client"
==9749== 
==9749== Invalid read of size 8
==9749==    at 0x400607: main (an.c:13)
==9749==  Address 0x51fc068 is 24 bytes after a block of size 16 in arena "client"
==9749== 
==9749== Invalid write of size 2
==9749==    at 0x4C2F7E3: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9749==    by 0x40061B: main (an.c:13)
==9749==  Address 0x50 is not stack'd, malloc'd or (recently) free'd
==9749== 
==9749== 
==9749== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==9749==  Access not within mapped region at address 0x50
==9749==    at 0x4C2F7E3: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9749==    by 0x40061B: main (an.c:13)
==9749==  If you believe this happened as a result of a stack
==9749==  overflow in your program's main thread (unlikely but
==9749==  possible), you can try to increase the size of the
==9749==  main thread stack using the --main-stacksize= flag.
==9749==  The main thread stack size used in this run was 8388608.
==9749== 
==9749== HEAP SUMMARY:
==9749==     in use at exit: 3 bytes in 1 blocks
==9749==   total heap usage: 1 allocs, 0 frees, 3 bytes allocated
==9749== 
==9749== LEAK SUMMARY:
==9749==    definitely lost: 0 bytes in 0 blocks
==9749==    indirectly lost: 0 bytes in 0 blocks
==9749==      possibly lost: 0 bytes in 0 blocks
==9749==    still reachable: 3 bytes in 1 blocks
==9749==         suppressed: 0 bytes in 0 blocks
==9749== Rerun with --leak-check=full to see details of leaked memory
==9749== 
==9749== For counts of detected and suppressed errors, rerun with: -v
==9749== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 0 from 0)
Segmentation fault

Si no lo sabía, ya descubrió que se memtrata de memoria asignada en el montón; El montón se refiere a la región de memoria disponible para el programa en tiempo de ejecución, porque el programa lo solicitó explícitamente (con malloc en nuestro caso).

Si juegas con el código terrible, encontrarás que no todas esas declaraciones obviamente incorrectas resultan en una falla de segmentación (un error de terminación fatal).

Cometí explícitamente esos errores en el código de ejemplo, pero los mismos tipos de errores ocurren muy fácilmente en un entorno administrado por memoria: si algún código no mantiene el recuento de una variable (u otro símbolo) de la manera correcta, por ejemplo si lo libera demasiado pronto, puede leerse otro fragmento de código de la memoria ya liberada, si de alguna manera almacena la dirección incorrecta, otro fragmento de código puede escribir en una memoria no válida, puede liberarse dos veces ...

Estos no son problemas que se puedan depurar en PHP, requieren absolutamente la atención de un desarrollador interno.

El curso de acción debe ser:

1. Abra un informe de error en http://bugs.php.net
   • Si usted tiene un error de segmentación, trata de proporcionar una traza inversa
   • Incluya toda la información de configuración que parezca apropiada, en particular, si está utilizando opcache, incluya el nivel de optimización.
   • Siga revisando el informe de errores para obtener actualizaciones, se puede solicitar más información.
2. Si tiene opcache cargado, deshabilite las optimizaciones
   • No estoy eligiendo opcache, es genial, pero se sabe que algunas de sus optimizaciones causan fallas.
   • Si eso no funciona, aunque su código sea más lento, primero intente descargar opcache.
   • Si algo de esto cambia o soluciona el problema, actualice el informe de error que realizó.
3. Deshabilite todas las extensiones innecesarias a la vez.
   • Comience a habilitar todas sus extensiones individualmente, realizando pruebas exhaustivas después de cada cambio de configuración.
   • Si encuentra la extensión del problema, actualice su informe de errores con más información.
4. Lucro.

Puede que no haya ningún beneficio ... Dije al principio, es posible que pueda encontrar una manera de cambiar sus síntomas jugando con la configuración, pero esto es extremadamente impredecible y no ayuda la próxima vez que tenga el mismo zend_mm_heap corruptedmensaje, solo hay muchas opciones de configuración.

Es realmente importante que creemos informes de errores cuando los encontremos, no podemos suponer que la próxima persona que lo haga lo hará ... lo más probable es que la resolución real no sea misteriosa, si usted hace el personas adecuadas conscientes del problema.

USE_ZEND_ALLOC

Si configura USE_ZEND_ALLOC=0en el entorno, esto desactiva el propio administrador de memoria de Zend; El administrador de memoria de Zend garantiza que cada solicitud tenga su propio montón, que toda la memoria se libere al final de una solicitud y que esté optimizada para la asignación de fragmentos de memoria del tamaño adecuado para PHP.

Deshabilitarlo deshabilitará esas optimizaciones, lo que es más importante, probablemente creará pérdidas de memoria, ya que hay una gran cantidad de código de extensión que depende del Zend MM para liberar memoria al final de una solicitud (tut, tut).

También puede ocultar los síntomas, pero el montón del sistema se puede dañar exactamente de la misma manera que el montón de Zend.

Puede parecer que ser más tolerantes o menos tolerantes, pero solucionar la causa raíz del problema, no se puede .

La capacidad de deshabilitarlo es para beneficio de los desarrolladores internos; Usted debe nunca se desplegará PHP con Zend MM desactivado.

Recibía este mismo error en PHP 5.5 y el aumento del búfer de salida no ayudó. Tampoco estaba ejecutando APC, así que ese no era el problema. Finalmente lo rastreé hasta opcache , simplemente tuve que deshabilitarlo desde el cli. Había una configuración específica para esto:

opcache.enable_cli=0

Una vez cambiado, el error corrupto zend_mm_heap desapareció.

Si está en la caja de Linux, intente esto en la línea de comando

export USE_ZEND_ALLOC=0

Verifique por unset()s. Asegúrese de no hacer unset()referencia a los $this(o equivalentes) en los destructores y que unset()los destructores no causen que el recuento de referencias al mismo objeto caiga a 0. He investigado un poco y descubrí que eso es lo que generalmente causa el montón corrupción.

Hay un informe de error de PHP sobre el error corrupto zend_mm_heap . Vea el comentario [2011-08-31 07:49 UTC] f dot ardelian at gmail dot compara ver un ejemplo sobre cómo reproducirlo.

Tengo la sensación de que todas las otras "soluciones" (cambiar php.ini, compilar PHP desde la fuente con menos módulos, etc.) simplemente ocultan el problema.

Para mí, ninguna de las respuestas anteriores funcionó, hasta que intenté:

opcache.fast_shutdown=0

Eso parece funcionar hasta ahora.

Estoy usando PHP 5.6 con PHP-FPM y Apache proxy_fcgi, si eso importa ...

En mi caso, la causa de este error fue que uno de los arreglos se estaba volviendo muy grande. He configurado mi script para restablecer la matriz en cada iteración y eso solucionó el problema.

Según el rastreador de errores, establezca opcache.fast_shutdown=0. El apagado rápido usa el administrador de memoria Zend para limpiar su desorden, esto lo deshabilita.

No creo que haya una respuesta aquí, así que agregaré mi experiencia. Vi este mismo error junto con segfaults httpd aleatorios. Este era un servidor cPanel. El síntoma en cuestión era que Apache restablecería la conexión aleatoriamente (no se recibieron datos en Chrome, o la conexión se restableció en Firefox). Estos fueron aparentemente aleatorios, la mayoría de las veces funcionó, a veces no.

Cuando llegué a la escena, el búfer de salida estaba apagado. Al leer este hilo, que insinuaba el búfer de salida, lo encendí (= 4096) para ver qué pasaría. En este punto, todos comenzaron a mostrar los errores. Esto fue bueno ya que el error ahora era repetible.

Lo revisé y comencé a deshabilitar las extensiones. Entre ellos, eaccellerator, pdo, cargador de ioncube, y muchos que parecían sospechosos, pero ninguno ayudó.

Finalmente encontré la extensión PHP traviesa como "homeloader.so", que parece ser algún tipo de módulo cPanel-easy-installer. Después de la eliminación, no he experimentado ningún otro problema.

En esa nota, parece que este es un mensaje de error genérico, por lo que su kilometraje variará con todas estas respuestas, el mejor curso de acción que puede tomar:

• Haga que el error sea repetible (¿qué condiciones?) Cada vez
• Encuentra el factor común
• Desactive selectivamente cualquier módulo PHP, opciones, etc. (o, si tiene prisa, desactívelos todos para ver si ayuda, luego vuelva a habilitarlos selectivamente hasta que se rompa nuevamente)
• Si esto no ayuda, muchas de estas respuestas sugieren que podría ser liberado por código. Una vez más, la clave es hacer que el error sea repetible en cada solicitud para que pueda reducirlo. Si sospecha que una pieza de código está haciendo esto, una vez más, después de que el error es repetible, simplemente elimine el código hasta que se detenga. Una vez que se detiene, sabe que el último código que eliminó fue el culpable.

Si falla todo lo anterior, también puede probar cosas como:

• Actualización o recompilación de PHP. Espero que cualquier error que esté causando su problema esté solucionado.
• Mueva su código a un entorno diferente (de prueba). Si esto soluciona el problema, ¿qué cambió? php.ini opciones? Versión PHP? etc ...

Buena suerte.

Luché con este problema, durante una semana, esto funcionó para mí, o al menos eso parece

En php.inihacer estos cambios

report_memleaks = Off  
report_zend_debug = 0  

Mi configuración es

Linux ubuntu 2.6.32-30-generic-pae #59-Ubuntu SMP  
with PHP Version 5.3.2-1ubuntu4.7  

Esto no funcionó.

Así que intenté usar un guión de referencia e intenté grabar donde estaba colgando el guión. Descubrí que justo antes del error, se instanciaba un objeto php, y tardó más de 3 segundos en completar lo que se suponía que debía hacer el objeto, mientras que en los bucles anteriores tardó un máximo de 0,4 segundos. Realicé esta prueba varias veces, y cada vez lo mismo. Pensé que en lugar de hacer un nuevo objeto cada vez (hay un ciclo largo aquí), debería reutilizar el objeto. He probado el script más de una docena de veces hasta ahora, ¡y los errores de memoria han desaparecido!

Busque cualquier módulo que use almacenamiento en búfer y desactívelo selectivamente.

Estoy ejecutando PHP 5.3.5 en CentOS 4.8, y después de hacer esto encontré que eaccelerator necesitaba una actualización.

También tuve este problema en un servidor que poseo, y la causa raíz fue APC. Comenté la extensión "apc.so" en el archivo php.ini, volví a cargar Apache y los sitios volvieron a funcionar.

He intentado todo lo anterior y zend.enable_gc = 0 la única configuración que me ayudó.

PHP 5.3.10-1ubuntu3.2 con Suhosin-Patch (cli) (construido: 13 de junio de 2012 17:19:58)

Tuve este error al usar el controlador Mongo 2.2 para PHP:

$collection = $db->selectCollection('post');
$collection->ensureIndex(array('someField', 'someOtherField', 'yetAnotherField')); 

^^ NO FUNCIONA

$collection = $db->selectCollection('post');
$collection->ensureIndex(array('someField', 'someOtherField')); 
$collection->ensureIndex(array('yetAnotherField')); 

^^ FUNCIONA! (?!)

En PHP 5.3, después de muchas búsquedas, esta es la solución que funcionó para mí:

He desactivado la recolección de basura PHP para esta página agregando:

<? gc_disable(); ?>

hasta el final de la página problemática, que hizo desaparecer todos los errores.

fuente .

Creo que muchas razones pueden causar este problema. Y en mi caso, nombro 2 clases con el mismo nombre, y una intentará cargar otra.

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

Y causa este problema en mi caso.

(Usando laravel framework, ejecutando php artisan db: seed en real)

Tuve este mismo problema y cuando tuve una IP incorrecta para session.save_path para sesiones memcached. Cambiarlo a la IP correcta solucionó el problema.

Si está utilizando rasgos y el rasgo se carga después de la clase (es decir, el caso de carga automática), debe cargar el rasgo de antemano.

https://bugs.php.net/bug.php?id=62339

Nota: este error es muy muy aleatorio; Debido a su naturaleza.

Para mí, el problema era usar pdo_mysql. La consulta arrojó resultados de 1960. Traté de devolver 1900 registros y funciona. Entonces, el problema es pdo_mysql y una matriz demasiado grande. Reescribí la consulta con la extensión original de mysql y funcionó.

$link = mysql_connect('localhost', 'user', 'xxxx') or die(mysql_error());
mysql_select_db("db", $link);

Apache no informó ningún error anterior.

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)

"zend_mm_heap dañado" significa problemas con la administración de memoria. Puede ser causado por cualquier módulo PHP. En mi caso, la instalación de APC funcionó. En teoría, otros paquetes como eAccelerator, XDebug, etc. también pueden ayudar. O, si tiene ese tipo de módulos instalados, intente apagarlos.

Estoy escribiendo una extensión php y también encuentro este problema. Cuando llamo a una función externa con parámetros complicados desde mi extensión, aparece este error.

La razón es que no estoy asignando memoria para un parámetro (char *) en la función externa. Si está escribiendo el mismo tipo de extensión, preste atención a esto.

Para mí, fue el ZendDebugger lo que causó la pérdida de memoria y evitó que el MemoryManager se bloqueara.

Lo deshabilité y actualmente estoy buscando una versión más nueva. Si no puedo encontrar uno, voy a cambiar a xdebug ...

Como nunca encontré una solución a esto, decidí actualizar mi entorno LAMP. Fui a Ubuntu 10.4 LTS con PHP 5.3.x. Esto parece haber detenido el problema para mí.

En mi caso, olvidé seguir el código:

);

Jugué y lo olvidé en el código aquí y allá; en algunos lugares tuve corrupción de montón, algunos casos simplemente por un error de seg:

[Mié 08 de junio 17:23:21 2011] [aviso] señal de salida de pid 5720 de niño Fallo de segmentación (11)

Estoy en mac 10.6.7 y xampp.

También noté este error y los SIGSEGV al ejecutar código antiguo que usa '&' para forzar explícitamente referencias mientras se ejecuta en PHP 5.2+.

Ajuste

assert.active = 0 

en php.ini me ayudó (apagó las aserciones de tipo en la php5UTF8biblioteca y zend_mm_heap corrupteddesapareció)

Para mí, el problema era el demonio memcached bloqueado, ya que PHP estaba configurado para almacenar información de sesión en memcached. Estaba comiendo 100% de CPU y actuando raro. Después de que el problema de reinicio de memcached haya desaparecido.

Como ninguna de las otras respuestas lo resolvió, tuve este problema en php 5.4 cuando accidentalmente ejecuté un bucle infinito.

Algunos consejos que pueden ayudar a alguien

fedora 20, php 5.5.18

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;
    }
}

usando var_dummp () en realidad no es un error, se colocó solo para la depuración y se eliminará en el código de producción. Pero el lugar real donde ocurrió zend_mm_heap es el segundo lugar.

Estaba en la misma situación aquí, nada de lo anterior ayudó, y comprobando más en serio que encuentro mi problema, consiste en intentar hacer morir (encabezado ()) después de enviar alguna salida al búfer, el hombre que hizo esto en el Código se olvidó de los recursos de CakePHP y no hizo un simple "return $ this-> redirect ($ url)".

Intentando reinventar el pozo, este era el problema.

Espero que esta relación ayude a alguien!