¿Qué significa "zend_mm_heap corrupted"?

126

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

bkulyk
fuente
2
Solía USE_ZEND_ALLOC=0obtener el stacktrace en el registro de errores y encontré el error /usr/sbin/httpd: corrupted double-linked list, descubrí que comentarlo opcache.fast_shutdown=1funcionó para mí.
Spidfire
Sí, lo mismo aquí. También vea otro informe más abajo stackoverflow.com/a/35212026/35946
lkraav el
Tuve lo mismo con Laravel. Inyecté una clase en el constructor de otra clase. La clase que estaba inyectando, inyectaba la clase en la que se inyectó, básicamente creando una referencia circular que causaba el problema del montón.
Thomas
1
Reinicie el servidor Apache para obtener soluciones más rápidas y temporales :)
Leopathu

Respuestas:

52

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

dsmithers
fuente
59
Aumentar a qué? ¿Por qué este cambio haría que este error desapareciera?
JDS
2
@JDS esta respuesta ayuda a explicar qué es output_buffering y por qué aumentarlo puede ayudar a stackoverflow.com/a/2832179/704803
andrewtweber
8
@andrewtweber Sé lo que es ob, me preguntaba sobre los detalles específicos que quedaron fuera de la respuesta de dsmithers, ya que tenía el mismo mensaje de error que el op. Para el cierre: resultó que mi problema era una configuración mal configurada perteneciente a memcached. Gracias, sin embargo!
JDS
@JDS ¿qué configuración mal configurada?
Kyle Cronin
3
@KyleCronin nuestra plataforma de servicio utiliza Memcache en producción. Sin embargo, algunas instancias únicas (no producción / sandbox, clientes únicos) no usan memcache. En el último caso, tuve una configuración copiada de producción a un cliente único, y la configuración de memcache indicaba un URI de servidor de memcache que no estaba disponible en ese entorno. Eliminé la línea y deshabilité memcache en la aplicación, y el problema desapareció. Entonces, para resumir, un problema muy específico que se encuentra en un entorno específico, que podría no ser generalmente aplicable. Pero, ya que preguntaste ...
JDS
47

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.

Joe Watkins
fuente
¿Entonces el problema subyacente podría ser qué versión de PHP está ejecutando?
Ismael
@Ishmael Sí, así como las versiones de todas las extensiones, ya que la advertencia puede surgir de una extensión.
obispo
2
Esta respuesta parece ser la mejor para mí. Personalmente, he experimentado el problema varias veces y siempre estuvo relacionado con una extensión defectuosa (en mi caso, la biblioteca de ortografía Enchant). Además de PHP en sí, también podría ser un mal entorno (desajuste de versión de lib, dependencias incorrectas, etc.)
Fractalizer
1
De lejos, la mejor respuesta para esta pregunta, y también para muchas otras preguntas similares
Nikita 웃
Esta respuesta es realmente instructiva, pero creo que no es el trabajo de un desarrollador de aplicaciones depurar el núcleo del servidor. De hecho, es mucho más fácil si tiene un seguimiento completo de la pila, pero ¿qué sigue? pedir arreglarlo en una solicitud de extracción? No todos son devops o no pueden entender un lenguaje de bajo nivel como C. Lo contrario también es cierto. Entonces, al final, creo que sería mucho más fácil si los desarrolladores no cometieran errores de administración de memoria en primer lugar. Lo que, como sugiere, es algo común con opcache, pero no es sorprendente que no con todos los módulos, porque sabe que algunos desarrolladores saben cómo desarrollar.
job3dot5
46

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ó.

Justin MacLeod
fuente
¡El mismo problema y solución aquí! ¡Gracias!
Mauricio Sánchez
2
Enorme más 1 para esta publicación. Intentamos todo pero al final, solo esto funcionó.
Geoffrey Brier
77
Estoy seguro de que sabe que cli es la versión de línea de comando de php y no tiene nada que ver con el módulo php utilizado con el servidor web apache, por ejemplo, y tengo curiosidad por saber cómo ayudó la desactivación de opcache con cli. (Supongo que esto está sucediendo en el servidor web)
BIOHAZARD
@BioHazard, aparte de cli hay una configuración general opcache.enable = 0. Pero no necesariamente ayuda al caso
Konstantin Ivanov
Esta debería ser la respuesta aceptada a esta pregunta. Elevar el output_buffering no es la respuesta, ya que esto puede tener efectos secundarios negativos para su sitio web o aplicación, de acuerdo con la documentación en php.ini.
BlueCola
41

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

export USE_ZEND_ALLOC=0
Hittz
fuente
Esto me salvó! Agrego esto dentro del archivo de servicio php-fpm (anulación systemd)
fzerorubigd
Esto lo hizo por mi. Recuerde agregar esta línea /etc/apache2/envvarssi está ejecutando esto en el servidor ubuntu con apache y php instalados desde ppas (apt). PHP 7.0-RC4 comenzó a arrojar este error cuando lo instalé desde el repositorio de ondrej.
Pedro Cordeiro
Y también funciona en Windows:set USE_ZEND_ALLOC=0
Nabi KAZ
22

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.

f.ardeliano
fuente
66
Estaba recibiendo este problema con html dom simple, y cambié de un no establecido, a $ simplehtmldom-> clear () que resolvió mis problemas, ¡gracias!
alexkb
9

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 ...

Jesús Carrera
fuente
1
Hay un montón de respuestas "yo también" para todos los escenarios diferentes, pero esto parecía más similar a mi configuración, y auge: este cambio exacto parece haber eliminado mi problema.
lkraav
6

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.

Piotr
fuente
Esto lo hizo por mí, ¡gracias! No pensé que el recolector de basura liberaría la memoria de una referencia cíclica, así que no lo revisé.
medio rápido
5

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.

Taco de Wolff
fuente
Esto solucionó "zend_mm_heap corrupted" en nuestra versión CentOS Linux 7.2.1511, PHP 5.5.38. Ahora podemos reanudar el uso de opcode cache. Noche y día sin ella.
Richard Ginsberg
Gracias por el recordatorio, ¡este fue exactamente mi problema!
Weasler
4

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.

AB Carroll
fuente
3

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!

sam
fuente
1
Esto funcionó por un tiempo, pero el error ha vuelto. ¿Cómo paro esto?
Sam
Esto mismo funcionó para mí en Mac Mavericks con MAMP PRO 2.1.1.
MutantMahesh
Esta solución no solucionó el problema de forma permanente, empiezo a recibir este error nuevamente.
MutantMahesh
77
¿Seguramente esto solo apaga la notificación de los errores en lugar de solucionar el problema?
Robert fue el
2

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.

Scott Davey
fuente
2

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.

Vance Lucas
fuente
2

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)

Bethrezen
fuente
2

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

hernanc
fuente
Esta respuesta me ayudó a depurar, siguiendo el camino del problema de Mongo. En mi caso, el controlador PHP 5.6 + Mongo 1.6.9, el mensaje corrupto zend_mm_heap se lanzó al iterar y consultar valores de una matriz previamente poblada a través deforeach(selectCollection()->find()) { $arr = .. }
Mihai MATEI
2

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 .

Kuf
fuente
2

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)

Yarco
fuente
1

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.

Travis Derouin
fuente
1

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.

srcspider
fuente
1

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)
banda ancha
fuente
1

"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.

Muto
fuente
1

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.

cedricliang
fuente
0

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 ...

Estructurado
fuente
0

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í.

bkulyk
fuente
0

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.

dsomnus
fuente
0

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+.

Phillip Whelan
fuente
0

Ajuste

assert.active = 0 

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

Vasiliy
fuente
0

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.

Justinas Jaronis
fuente
0

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

Mikayla Maki
fuente
0

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.

Lexand
fuente
0

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!

Newton Pasqualini Filho
fuente