Que signifie «zend_mm_heap corrompu»

127

Tout à coup, j'ai eu des problèmes avec mon application que je n'avais jamais eu auparavant. J'ai décidé de vérifier le journal des erreurs d'Apache et j'ai trouvé un message d'erreur disant "zend_mm_heap corrompu". Qu'est-ce que ça veut dire.

Système d'exploitation: Fedora Core 8 Apache: 2.2.9 PHP: 5.2.6

bkulyk
la source
2
J'avais l'habitude USE_ZEND_ALLOC=0d'obtenir le stacktrace dans le journal des erreurs Et /usr/sbin/httpd: corrupted double-linked listj'ai trouvé le bogue , j'ai découvert que commenter le opcache.fast_shutdown=1fonctionnait pour moi.
Spidfire
Oui le même ici. Voir également un autre rapport ci-dessous stackoverflow.com/a/35212026/35946
lkraav
J'ai eu la même chose en utilisant Laravel. J'ai injecté une classe dans le constructeur d'une autre classe. La classe que j'injectais injectait la classe dans laquelle elle avait été injectée, créant essentiellement une référence circulaire causant le problème du tas.
Thomas
1
Redémarrez le serveur Apache pour les solutions les plus rapides et temporaires :)
Leopathu

Réponses:

52

Après de nombreux essais et erreurs, j'ai trouvé que si j'augmente la output_bufferingvaleur dans le fichier php.ini, cette erreur disparaît

dsmithers
la source
59
Augmenter à quoi? Pourquoi ce changement ferait-il disparaître cette erreur?
JDS
2
@JDS cette réponse aide à expliquer ce qu'est output_buffering et pourquoi son augmentation peut aider stackoverflow.com/a/2832179/704803
andrewtweber
8
@andrewtweber Je sais ce qu'est ob, je m'interrogeais sur les détails spécifiques qui ont été omis de la réponse des dsmithers, car j'avais le même message d'erreur que l'op. Pour terminer: il s'est avéré que mon problème était un paramètre mal configuré concernant Memcached. Merci quand même!
JDS
@JDS quel paramètre mal configuré?
Kyle Cronin
3
@KyleCronin notre plate-forme de service utilise Memcache en production. Cependant, certaines instances uniques - hors production / sandbox, clients ponctuels - n'utilisent pas Memcache. Dans ce dernier cas, j'avais une configuration copiée de la production vers un client unique, et la configuration Memcache indiquait un URI de serveur Memcache qui n'était pas disponible dans cet environnement. J'ai supprimé la ligne et désactivé Memcache dans l'application, et le problème a disparu. Donc, en bref, un problème très spécifique rencontré dans un environnement spécifique, qui pourrait ne pas être généralement applicable. Mais, puisque vous avez demandé ...
JDS
47

Ce n'est pas un problème qui peut nécessairement être résolu en modifiant les options de configuration.

Changer les options de configuration aura parfois un impact positif, mais cela peut tout aussi facilement aggraver les choses, ou ne rien faire du tout.

La nature de l'erreur est la suivante:

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

Le code ci-dessus peut être compilé avec:

gcc -g -o corrupt corrupt.c

En exécutant le code avec valgrind, vous pouvez voir de nombreuses erreurs de mémoire, aboutissant à une erreur de segmentation:

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 vous ne le saviez pas, vous avez déjà compris qu'il mems'agit de la mémoire allouée au tas; Le tas fait référence à la région de mémoire disponible pour le programme à l'exécution, car le programme l'a explicitement demandé (avec malloc dans notre cas).

Si vous jouez avec le terrible code, vous constaterez que toutes ces déclarations manifestement incorrectes ne provoquent pas une erreur de segmentation (une erreur de fin fatale).

J'ai explicitement fait ces erreurs dans l'exemple de code, mais les mêmes types d'erreurs se produisent très facilement dans un environnement géré en mémoire: si un code ne maintient pas le refcount d'une variable (ou d'un autre symbole) de la manière correcte, par exemple s'il est libre, c'est trop tôt, un autre morceau de code peut lire à partir de la mémoire déjà libérée, s'il stocke d'une manière ou d'une autre l'adresse incorrecte, un autre morceau de code peut écrire dans une mémoire invalide, il peut être libéré deux fois ...

Ce ne sont pas des problèmes qui peuvent être débogués en PHP, ils nécessitent absolument l'attention d'un développeur interne.

Le plan d'action devrait être:

  1. Ouvrez un rapport de bogue sur http://bugs.php.net
    • Si vous avez un segfault, essayez de fournir un backtrace
    • Incluez autant d'informations de configuration que vous le souhaitez, en particulier si vous utilisez opcache, incluez le niveau d'optimisation.
    • Continuez à vérifier le rapport de bogue pour les mises à jour, plus d'informations peuvent être demandées.
  2. Si vous avez chargé opcache, désactivez les optimisations
    • Je ne choisis pas opcache, c'est génial, mais certaines de ses optimisations sont connues pour causer des erreurs.
    • Si cela ne fonctionne pas, même si votre code peut être plus lent, essayez d'abord de décharger opcache.
    • Si l'un de ces changements ou corrige le problème, mettez à jour le rapport de bogue que vous avez effectué.
  3. Désactivez toutes les extensions inutiles à la fois.
    • Commencez à activer toutes vos extensions individuellement, en effectuant des tests approfondis après chaque changement de configuration.
    • Si vous trouvez l'extension du problème, mettez à jour votre rapport de bogue avec plus d'informations.
  4. Profit.

Il n'y a peut-être aucun profit ... J'ai dit au début, vous pourrez peut-être trouver un moyen de changer vos symptômes en jouant avec la configuration, mais c'est extrêmement hasardeux, et n'aide pas la prochaine fois que vous avez le même zend_mm_heap corruptedmessage, il n'y a que tellement d'options de configuration.

Il est vraiment important que nous créions des rapports de bogues lorsque nous trouvons des bogues, nous ne pouvons pas supposer que la prochaine personne à frapper le bogue va le faire ... plus probable qu'autrement, la résolution réelle n'est en aucun cas mystérieuse, si vous faites le les bonnes personnes conscientes du problème.

USE_ZEND_ALLOC

Si vous définissez USE_ZEND_ALLOC=0dans l'environnement, cela désactive le propre gestionnaire de mémoire de Zend; Le gestionnaire de mémoire de Zend garantit que chaque requête a son propre tas, que toute la mémoire est libérée à la fin d'une requête et est optimisé pour l'allocation de blocs de mémoire de la bonne taille pour PHP.

Le désactiver désactivera ces optimisations, plus important encore, cela créera probablement des fuites de mémoire, car il y a beaucoup de code d'extension qui s'appuie sur le Zend MM pour libérer de la mémoire pour eux à la fin d'une requête (tut, tut).

Cela peut également masquer les symptômes, mais le tas système peut être corrompu exactement de la même manière que le tas de Zend.

Cela peut sembler plus ou moins tolérant, mais il ne peut pas résoudre la cause profonde du problème .

La possibilité de le désactiver du tout, est au profit des développeurs internes; Vous ne devez jamais déployer PHP avec Zend MM désactivé.

Joe Watkins
la source
Le problème sous-jacent pourrait donc être la version de PHP que vous utilisez?
Ishmael
@Ishmael Oui, ainsi que les versions de toutes les extensions, car l'avertissement peut provenir d'une extension.
évêque
2
Cette réponse semble être la meilleure pour moi. J'ai personnellement rencontré le problème à quelques reprises et il était toujours lié à une extension défectueuse (dans mon cas, la bibliothèque d'orthographe Enchant). Autre que php lui-même, cela pourrait aussi être un mauvais environnement (incompatibilité de version de lib, mauvaises dépendances, etc.)
Fractalizer
1
De loin, la meilleure réponse à cette question, ainsi qu'à de nombreuses autres questions similaires
Nikita 웃
Cette réponse est en effet instructive mais je pense que ce n'est pas le travail d'un développeur d'applications de déboguer le cœur du serveur. En effet, c'est beaucoup plus facile si vous avez une trace de pile complète, mais quelle est la prochaine étape? demander de le réparer sur une pull request? Tout le monde n'est pas devops ou n'est pas capable de comprendre un langage de bas niveau comme C. Le contraire est également vrai. Donc, à la fin, je pense que ce serait beaucoup plus facile si les développeurs ne feraient pas d'erreurs de gestion de la mémoire en premier lieu. Ce qui, comme vous le suggérez, est un peu commun avec opcache, mais ce n'est pas surprenant avec tous les modules, car vous savez que certains développeurs savent comment développer.
job3dot5
46

J'obtenais cette même erreur sous PHP 5.5 et l'augmentation de la mémoire tampon de sortie n'a pas aidé. Je n'utilisais pas APC non plus, ce n'était donc pas le problème. Je l'ai finalement retracé jusqu'à opcache , j'ai simplement dû le désactiver du cli. Il y avait un paramètre spécifique pour cela:

opcache.enable_cli=0

Une fois commuté, l'erreur corrompue zend_mm_heap a disparu.

Justin MacLeod
la source
Même problème et même solution ici! Merci!
Mauricio Sánchez
2
Énorme plus 1 pour ce poste. Nous avons tout essayé mais à la fin, seul cela a fonctionné.
Geoffrey Brier
7
Je suis sûr que vous savez que cli est une version en ligne de commande de php et que cela n'a rien à voir avec le module php utilisé avec le serveur Web Apache par exemple et je suis curieux de savoir comment la désactivation d'opcache avec cli a aidé? (Je suppose que cela se produit sur le serveur Web)
BIOHAZARD
@BioHazard, à part cli, il existe un paramètre général opcache.enable = 0. Mais cela n'aide pas nécessairement l'affaire
Konstantin Ivanov
Cela devrait être la réponse acceptée à cette question. Augmenter le output_buffering n'est pas la réponse, car cela peut avoir des effets secondaires négatifs sur votre site Web ou votre application, selon la documentation de php.ini.
BlueCola
41

Si vous êtes sous Linux, essayez ceci sur la ligne de commande

export USE_ZEND_ALLOC=0
Hittz
la source
Cela m'a sauvé! J'ajoute cela dans le fichier de service php-fpm (remplacement de systemd)
fzerorubigd
Cela l'a fait pour moi. N'oubliez pas d'ajouter cette ligne /etc/apache2/envvarssi vous l'exécutez sur un serveur ubuntu avec apache et php installés à partir du ppas (apt). PHP 7.0-RC4 a commencé à générer cette erreur lorsque je l'ai installé à partir du référentiel ondrej.
Pedro Cordeiro
Et aussi ça marche sur windows:set USE_ZEND_ALLOC=0
Nabi KAZ
22

Vérifiez unset()s. Assurez-vous de ne pas faire unset()référence aux $this(ou équivalents) dans les destructeurs et queunset() s dans les destructeurs ne font pas chuter le nombre de références au même objet à 0. J'ai fait des recherches et j'ai trouvé que c'est ce qui cause généralement le tas la corruption.

Il existe un rapport de bogue PHP concernant l' erreur corrompue zend_mm_heap . Voir le commentaire[2011-08-31 07:49 UTC] f dot ardelian at gmail dot com pour un exemple sur la façon de le reproduire.

J'ai le sentiment que toutes les autres «solutions» (changer php.ini, compiler PHP à partir des sources avec moins de modules, etc.) ne font que cacher le problème.

f. cardélien
la source
6
J'obtenais ce problème avec un simple dom html, et je suis passé d'un non défini à $ simplehtmldom-> clear () qui a résolu mes problèmes, merci!
alexkb
9

Pour moi, aucune des réponses précédentes n'a fonctionné, jusqu'à ce que j'essaye:

opcache.fast_shutdown=0

Cela semble fonctionner jusqu'à présent.

J'utilise PHP 5.6 avec PHP-FPM et Apache proxy_fcgi, si cela compte ...

Jesús Carrera
la source
1
Il y a une tonne de réponses "moi aussi" pour tous les différents scénarios, mais cela semblait plus similaire à ma configuration, et boum - ce changement exact semble avoir éliminé mon problème.
lkraav
6

Dans mon cas, la cause de cette erreur était que l'un des tableaux devenait très gros. J'ai configuré mon script pour réinitialiser le tableau à chaque itération et cela a résolu le problème.

Piotr
la source
Cela l'a fait pour moi - merci! Je ne pensais pas que le garbage collector libérerait la mémoire d'une référence cyclique, donc je ne l'ai pas vérifié.
mi-temps
5

Selon le suivi des bogues, définissez opcache.fast_shutdown=0. L'arrêt rapide utilise le gestionnaire de mémoire Zend pour nettoyer son désordre, cela le désactive.

Taco de Wolff
la source
Ce correctif "zend_mm_heap corrompu" sur notre version Linux CentOS 7.2.1511, PHP 5.5.38. Nous sommes maintenant en mesure de reprendre l'utilisation du cache opcode. Nuit et jour sans elle.
Richard Ginsberg
Merci pour le rappel, c'était exactement mon problème!
Weasler
4

Je ne pense pas qu'il y ait une seule réponse ici, alors j'ajouterai mon expérience. J'ai vu cette même erreur avec des segfaults httpd aléatoires. C'était un serveur cPanel. Le symptôme en question était qu'apache réinitialisait aléatoirement la connexion (aucune donnée reçue dans Chrome, ou la connexion a été réinitialisée dans Firefox). Celles-ci étaient apparemment aléatoires - la plupart du temps, cela fonctionnait, parfois cela ne fonctionnait pas.

Quand je suis arrivé sur la scène, la mise en mémoire tampon de sortie était désactivée. En lisant ce fil, qui faisait allusion à la mise en mémoire tampon de sortie, je l'ai activé (= 4096) pour voir ce qui se passerait. À ce stade, ils ont tous commencé à montrer les erreurs. C'était bien étant que l'erreur était désormais répétable.

Je suis passé et j'ai commencé à désactiver les extensions. Parmi eux, eaccellerator, pdo, chargeur ioncube, et beaucoup qui avaient l' air suspects, mais aucun n'a aidé.

J'ai finalement trouvé la vilaine extension PHP comme "homeloader.so", qui semble être une sorte de module d'installation cPanel-easy. Après la suppression, je n'ai rencontré aucun autre problème.

Sur cette note, il semble qu'il s'agisse d'un message d'erreur générique de sorte que votre kilométrage variera avec toutes ces réponses, meilleur plan d'action que vous pouvez prendre:

  • Rendre l'erreur répétable (quelles conditions?) À chaque fois
  • Trouvez le facteur commun
  • Désactivez sélectivement tous les modules PHP, options, etc. (ou, si vous êtes pressé, désactivez-les tous pour voir si cela aide, puis réactivez-les de manière sélective jusqu'à ce qu'il se brise à nouveau)
  • Si cela ne résout pas le problème, beaucoup de ces réponses suggèrent que le code pourrait être recréé. Encore une fois, la clé est de rendre l'erreur répétable à chaque demande afin que vous puissiez la réduire. Si vous pensez qu'un morceau de code le fait, encore une fois, une fois l'erreur répétable, supprimez simplement le code jusqu'à ce que l'erreur s'arrête. Une fois qu'il s'arrête, vous savez que le dernier morceau de code que vous avez supprimé était le coupable.

À défaut de tout ce qui précède, vous pouvez également essayer des choses comme:

  • Mettre à jour ou recompiler PHP. J'espère que le bogue qui cause votre problème est corrigé.
  • Déplacez votre code vers un autre environnement (de test). Si cela résout le problème, qu'est-ce qui a changé? options php.ini? Version PHP? etc...

Bonne chance.

AB Carroll
la source
3

J'ai lutté avec ce problème, pendant une semaine, cela a fonctionné pour moi, ou du moins il semble

En php.iniapportant ces changements

report_memleaks = Off  
report_zend_debug = 0  

Ma configuration est

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

Cela n'a pas fonctionné.

J'ai donc essayé d'utiliser un script de référence et essayé d'enregistrer là où le script se raccrochait. J'ai découvert que juste avant l'erreur, un objet php était instancié et que cela prenait plus de 3 secondes pour terminer ce que l'objet était censé faire, alors que dans les boucles précédentes, cela prenait au maximum 0,4 seconde. J'ai effectué ce test plusieurs fois, et à chaque fois de la même manière. J'ai pensé qu'au lieu de créer un nouvel objet à chaque fois (il y a une longue boucle ici), je devrais réutiliser l'objet. J'ai testé le script plus d'une douzaine de fois jusqu'à présent, et les erreurs de mémoire ont disparu!

sam
la source
1
Cela a fonctionné pendant un certain temps, mais l'erreur est de retour. Comment puis-je arrêter cela?
sam
Cela a fonctionné pour moi sur les mavericks mac avec MAMP PRO 2.1.1.
MutantMahesh
Cette solution n'a pas résolu le problème de manière permanente, je recommence à recevoir cette erreur.
MutantMahesh
7
Il s'agit sûrement simplement de désactiver le signalement des erreurs plutôt que de résoudre le problème?
Robert est allé le
2

Recherchez tout module qui utilise la mise en mémoire tampon et désactivez-le de manière sélective.

J'utilise PHP 5.3.5 sur CentOS 4.8, et après cela, j'ai trouvé qu'eaccelerator avait besoin d'une mise à niveau.

Scott Davey
la source
2

J'ai juste eu ce problème sur un serveur que je possède, et la cause principale était APC. J'ai commenté l'extension "apc.so" dans le fichier php.ini, rechargé Apache, et les sites sont revenus immédiatement.

Vance Lucas
la source
2

J'ai tout essayé ci-dessus et zend.enable_gc = 0 - le seul paramètre de configuration, qui m'a aidé.

PHP 5.3.10-1ubuntu3.2 avec Suhosin-Patch (cli) (construit: 13 juin 2012 17:19:58)

Bethrezen
la source
2

J'ai eu cette erreur en utilisant le pilote Mongo 2.2 pour PHP:

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

^^ NE FONCTIONNE PAS

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

^^ FONCTIONNE! (?!)

hernanc
la source
Cette réponse m'a aidé à déboguer, en suivant le chemin du problème Mongo. Dans mon cas, pilote PHP 5.6 + Mongo 1.6.9, le message corrompu zend_mm_heap a été lancé lors de l'itération et de la requête des valeurs d'un tableau précédemment foreach(selectCollection()->find()) { $arr = .. }
rempli
2

Sur PHP 5.3, après de nombreuses recherches, voici la solution qui a fonctionné pour moi:

J'ai désactivé le garbage collection PHP pour cette page en ajoutant:

<? gc_disable(); ?>

à la fin de la page problématique, qui a fait disparaître toutes les erreurs.

source .

Kuf
la source
2

Je pense que beaucoup de raisons peuvent causer ce problème. Et dans mon cas, je nomme 2 classes du même nom, et on essaiera d'en charger une autre.

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

Et cela cause ce problème dans mon cas.

(Utilisation du framework laravel, exécution de php artisan db: seed en réel)

Yarco
la source
1

J'ai eu ce même problème et quand j'avais une adresse IP incorrecte pour session.save_path pour les sessions memcached. Le changer à l'adresse IP correcte a résolu le problème.

Travis Derouin
la source
1

Si vous utilisez des traits et que le trait est chargé après la classe (c'est-à-dire dans le cas du chargement automatique), vous devez charger le trait au préalable.

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

Remarque: ce bug est très très aléatoire; en raison de sa nature.

srcspider
la source
1

Pour moi, le problème était d'utiliser pdo_mysql. La requête a renvoyé 1960 résultats. J'ai essayé de renvoyer 1900 enregistrements et cela fonctionne. Le problème est donc pdo_mysql et un tableau trop grand. J'ai réécrit la requête avec l'extension mysql d'origine et cela a fonctionné.

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

Apache n'a signalé aucune erreur précédente.

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)
haut débit
la source
1

"zend_mm_heap corrompu" signifie des problèmes de gestion de la mémoire. Peut être causé par n'importe quel module PHP. Dans mon cas, l'installation d'APC a fonctionné. En théorie, d'autres packages comme eAccelerator, XDebug etc. peuvent également aider. Ou, si vous avez installé ce type de modules, essayez de les désactiver.

Muto
la source
1

J'écris une extension php et rencontre également ce problème. Lorsque j'appelle une fonction externe avec des paramètres compliqués de mon extension, cette erreur apparaît.

La raison est que je n'alloue pas de mémoire pour un paramètre (char *) dans la fonction extern. Si vous écrivez le même type d'extension, veuillez faire attention à cela.

Cedricliang
la source
0

Pour moi, c'est le ZendDebugger qui a causé la fuite de mémoire et a provoqué le crash du MemoryManager.

Je l'ai désactivé et je recherche actuellement une version plus récente. Si je n'en trouve pas, je vais passer à xdebug ...

Structuré
la source
0

Parce que je n'ai jamais trouvé de solution à cela, j'ai décidé de mettre à niveau mon environnement LAMP. Je suis allé sur Ubuntu 10.4 LTS avec PHP 5.3.x. Cela semble avoir arrêté le problème pour moi.

bkulyk
la source
0

Dans mon cas, j'ai oublié de suivre dans le code:

);

J'ai joué et je l'ai oublié dans le code ici et là - à certains endroits, j'ai eu une corruption de tas, certains cas tout simplement une erreur de seg:

[Wed Jun 08 17:23:21 2011] [notice] signal de sortie enfant pid 5720 Erreur de segmentation (11)

Je suis sur mac 10.6.7 et xampp.

dsomnus
la source
0

J'ai également remarqué cette erreur et SIGSEGV lors de l'exécution d'un ancien code qui utilise '&' pour forcer explicitement les références lors de son exécution dans PHP 5.2+.

Phillip Whelan
la source
0

Réglage

assert.active = 0 

dans php.ini m'a aidé (il a désactivé les assertions de type dans la php5UTF8bibliothèque et zend_mm_heap corruptedest parti)

Vasiliy
la source
0

Pour moi, le problème était le démon memcached écrasé, car PHP était configuré pour stocker les informations de session dans memcached. Il mangeait 100% CPU et agissait bizarrement. Après que le problème de redémarrage de Memcached ait disparu.

Justinas Jaronis
la source
0

Comme aucune des autres réponses ne l'a abordé, j'ai eu ce problème dans php 5.4 lorsque j'ai accidentellement exécuté une boucle infinie.

Mikayla Maki
la source
0

Quelques conseils qui peuvent aider quelqu'un

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

l'utilisation de var_dummp () n'est en fait pas une erreur, elle a été placée juste pour le débogage et sera supprimée sur le code de production. Mais le vrai endroit où zend_mm_heap s'est produit est la deuxième place.

Lexand
la source
0

J'étais dans la même situation ici, rien ci-dessus n'a aidé, et en vérifiant plus sérieusement je trouve mon problème, il consiste à essayer de faire mourir (header ()) après avoir envoyé une sortie au tampon, l'homme qui a fait cela dans le Code a oublié les ressources de CakePHP et n'a pas fait un simple "return $ this-> redirect ($ url)".

Tenter de réinventer le puits, tel était le problème.

J'espère que ce rapport aide quelqu'un!

Newton Pasqualini Filho
la source