Qu'est-ce que « zend_mm_heap corrompu » signifie

Question

Tout à coup, j'ai eu des problèmes avec ma demande que je ne l'ai jamais eu auparavant. J'ai décidé de vérifier le journal des erreurs d'Apache, et j'ai trouvé un message d'erreur indiquant « zend_mm_heap corrompu ». Qu'est-ce que cela signifie.

OS: Fedora Core 8 Apache: 2.2.9 PHP: 5.2.6

Answer 1

Après plusieurs essais et erreurs, je trouve que si j'augmente la valeur de output_buffering dans le fichier php.ini, cette erreur disparaît

Answer 2

Je recevais cette même erreur en PHP 5.5 et l'augmentation de la mise en mémoire tampon de sortie n'a pas aidé. Je ne courais APC soit si ce n'était pas la question. J'ai finalement dépisté jusqu'à opcache , j'avais tout simplement de le désactiver à partir du cli. Il y avait un cadre spécifique pour ceci:

opcache.enable_cli=0

Une fois allumé l'erreur corrompu de zend_mm_heap est parti.

Answer 3

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

export USE_ZEND_ALLOC=0

Answer 4

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

Modification des options de configuration ont parfois un impact positif, mais il peut tout aussi bien faire empirer 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

L'exécution du 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 saviez pas, vous avez déjà compris que mem est la mémoire allouée en tas; Le tas fait référence à la région de mémoire disponible pour le programme lors de l'exécution, parce que le programme fait la demande explicite (avec malloc dans notre cas).

Si vous jouez avec le terrible code, vous trouverez que toutes ces déclarations manifestement faux résultats dans une erreur de segmentation (une erreur de terminaison fatale).

Je explicitement fait ces erreurs dans le code exemple, mais les mêmes types d'erreurs se faire très facilement dans un environnement géré de mémoire: Si un code ne maintient pas la refcount d'une variable (ou un autre symbole) de la manière correcte , par exemple si elle est libre trop tôt, un autre morceau de code peut lire de la mémoire déjà free'd, si elle stocke en quelque sorte la mauvaise adresse, un autre morceau de code peut écrire dans la mémoire non valide, il peut être free'd deux fois .. .

Ce ne sont pas des problèmes qui peuvent être débogué en PHP, ils ont absolument besoin de l'attention d'un développeur de composants internes.

Le cours de l'action devrait être:

1. Ouvrez un rapport de bogue sur http://bugs.php.net
   • Si vous avez un segfault, essayez de fournir un backtrace
   • inclure autant d'informations de configuration comme cela semble approprié, en particulier si vous utilisez opcache comprennent le niveau d'optimisation.
   • Consultez régulièrement le rapport de bogue pour les mises à jour, plus d'informations peuvent être demandées.
2. Si vous avez opcache chargé, désactivez les optimisations
   • Je ne suis pas sur la cueillette opcache, il est génial, mais certains de ses optimisations ont été connus pour causer des erreurs.
   • Si cela ne fonctionne pas, même si votre code peut être plus lent, essayez le déchargement opcache premier.
   • Si cela change ou résout le problème, mettez à jour le rapport de bogue que vous avez fait.
3. Désactiver toutes les extensions inutiles à la fois.
   • Commencer à activer toutes vos extensions individuellement, tester après chaque changement de configuration.
   • Si vous trouvez l'extension de problème, mettez à jour votre rapport de bug avec plus d'informations.
4. Profit.

Il ne peut y avoir de profit ... je l'ai dit au début, vous pourrez peut-être trouver un moyen de changer vos symptômes par Messing avec la configuration, mais cela est extrêmement hasardeux, et ne contribue pas à la prochaine le temps que vous avez le même message zend_mm_heap corrupted, il n'y a que tant d'options de configuration.

Il est vraiment important que nous créons des bugs rapports lorsque nous trouvons des bugs, nous ne pouvons pas supposer que la prochaine personne à frapper le bug va le faire ... plus que probable, la résolution réelle est en aucune façon mystérieuse, si vous faites les bonnes personnes au courant du problème.

USE_ZEND_ALLOC

Si vous définissez USE_ZEND_ALLOC=0 dans l'environnement, cette opération désactive propre gestionnaire de mémoire de Zend; Le gestionnaire de mémoire de Zend veille à ce que chaque demande a son propre tas, que toute la mémoire est free'd à la fin d'une demande, et est optimisé pour l'attribution des morceaux de mémoire juste la bonne taille pour PHP.

La désactivation de cette désactive ces optimisations, plus important encore, il va probablement créer des fuites de mémoire, car il y a beaucoup de code d'extension qui repose sur le Zend MM pour libérer la mémoire pour eux à la fin d'une demande (Tut, Tut).

Il peut également cacher les symptômes, mais le tas de système peut être corrompu en exactment de la même manière que le tas de Zend.

Il peut sembler être plus tolérant ou moins tolérant, mais fixer la cause racine du problème, il ne peut pas .

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

Answer 5

Vérifier unset()s. Assurez-vous que vous ne unset() pas de références à la $this (ou équivalents) et que dans Destructeurs unset()s à Destructeurs ne causent pas le compte de référence au même objet de laisser tomber à 0. Je l'ai fait des recherches et a constaté que ce qui est habituellement cause la corruption du tas.

Il y a un bug PHP rapport sur le zend_mm_heap corrompu erreur. 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 tous les autres « solutions » (changement php.ini, compiler PHP à partir des sources avec moins de modules, etc.) juste cacher le problème.

Answer 6

Pour moi, aucune des réponses précédentes a travaillé, jusqu'à ce que j'ai essayé:

opcache.fast_shutdown=0

Cela semble fonctionner jusqu'à présent.

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

Answer 7

Dans mon cas, la cause de cette erreur a été l'un des tableaux était en train de devenir très grand. J'ai mis mon script pour réinitialiser le tableau à chaque itération et que le problème triai.

Answer 8

Comme par le bug tracker, définissez opcache.fast_shutdown=0. arrêt rapide utilise le gestionnaire de mémoire Zend pour nettoyer son désordre, cela désactive cela.

Answer 9

Je ne pense pas qu'il y ait une réponse ici, donc je vais ajouter mon expérience. J'ai vu cette même erreur avec segfaults httpd au hasard. Ce fut un serveur cPanel. Le symptôme en question était apache au hasard serait réinitialiser la connexion (Aucune donnée reçue en chrome ou connexion a été réinitialisée dans Firefox). Ceux-ci étaient apparemment au hasard -. La plupart du temps, il a travaillé, parfois, il n'a pas

Quand je suis arrivé sur la mise en mémoire tampon de sortie de scène était OFF. En lisant ce fil, qui fait allusion à mémoire tampon de sortie, je l'ai allumé (= 4096) pour voir ce qui se passerait. À ce stade, ils tous a commencé à montrer les erreurs. Ce fut bien être que l'erreur était maintenant reproductible.

Je suis passé par et a commencé à la désactivation des extensions. Parmi eux, eaccellerator, pdo, chargeur ioncube, et beaucoup que regardé soupçon, mais aucun aidé.

J'ai finalement trouvé la vilaine extension PHP comme « homeloader.so », qui semble être une sorte de module de cPanel-installateur facile. Après le retrait, je ne l'ai pas connu d'autres problèmes.

Sur cette note, il semble que c'est un message d'erreur générique afin que votre milage variera avec toutes ces réponses, le meilleur plan d'action, vous pouvez prendre:

• l'erreur répétitive (quelles conditions?) À chaque fois
• Trouvez le facteur commun
• désactiver tous les modules de manière sélective PHP, options, etc (ou, si vous êtes pressé, désactivez tout pour voir si elle aide, puis les réactiver de manière sélective jusqu'à ce qu'il casse à nouveau)
• Si cela ne fonctionne pas pour aider, bon nombre de ces réponses laissent entendre que ce pourrait être le code releated. Encore une fois, la clé est de faire l'erreur répétitive chaque demande de sorte que vous pouvez le réduire. Si vous pensez qu'un morceau de code fait cela, encore une fois, une fois l'erreur est répétée, il suffit de retirer le code jusqu'à l'arrêt de l'erreur. Une fois qu'il arrête, vous savez le dernier morceau de code que vous avez retiré était le coupable.

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

• Mise à niveau ou recompiler PHP. Espoir tout bug qui cause votre problème est résolu.
• Déplacez votre code dans un environnement différent (test). Si cela résout le problème, ce qui a changé? Options php.ini? PHP version? etc ...

Bonne chance.

Answer 10

Je débattais avec cette question, pour une semaine, Cela a fonctionné pour moi, ou du moins il semble

Dans php.ini effectuer ces modifications

report_memleaks = Off  
report_zend_debug = 0  

Mon mise en place est

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

Cela ne fonctionne pas.

J'ai essayé d'utiliser un script de référence, et essayé d'enregistrement où le script accrochait. J'ai découvert que juste avant l'erreur, un objet php a été instancié, et il a fallu plus de 3 secondes pour compléter ce que l'objet était censé faire, alors que dans les boucles précédentes il a fallu 0,4 secondes max. J'ai couru ce test à quelques reprises, et à chaque fois la même chose. Je pensais au lieu de faire un nouvel objet à chaque fois, (il y a une longue boucle ici), je réutiliser l'objet. J'ai testé le script plus d'une douzaine de fois à ce jour, et les erreurs de mémoire ont disparu!

Answer 11

Rechercher un module qui utilise en mémoire tampon, et désactiver sélectivement.

Je suis en cours d'exécution PHP 5.3.5 sur CentOS 4.8, et après avoir fait ce que j'ai trouvé eaccelerator besoin d'une mise à niveau.

Answer 12

Je viens d'avoir ce problème aussi bien sur un serveur que je possède, et la cause était APC. Je commentais l'extension « apc.so » dans le fichier php.ini, rechargées Apache, et les sites venu droit vers le haut.

Answer 13

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

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

Answer 14

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')); 

^^ ça marche! (?!)

Answer 15

En PHP 5.3, après beaucoup de de recherche, c'est la solution qui a fonctionné pour moi:

J'ai désactivé la collecte des ordures PHP pour cette page par en ajoutant:

<? gc_disable(); ?>

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

la source .

Answer 16

Je pense que beaucoup de raison peut causer ce problème. Et dans mon cas, je nomme 2 classes du même nom, et on essayera de charger une autre.

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

Et il provoque ce problème dans mon cas.

(avec cadre Laravel, en cours d'exécution artisan php db: graines en temps réel)

Answer 17

J'eu ce même problème et quand j'eu une adresse IP incorrecte pour session.save_path pour les sessions memcached. Changement à la propriété intellectuelle correcte résolu le problème.

Answer 18

Si vous utilisez des caractères et le trait est chargé après la classe (ie. Le cas de l'auto-chargement) vous devez charger le trait au préalable.

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

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

Answer 19

Pour moi, le problème en utilisant pdo_mysql. Requête a retourné 1960 résultats. J'ai essayé de revenir 1900 records et il fonctionne. Donc problème est pdo_mysql et le réseau trop grand. Je réécris requête avec l'extension originale de MySQL et cela a fonctionné.

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

Apache n'a pas signalé des erreurs précédentes.

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)

Answer 20

« zend_mm_heap corrompu » signifie des problèmes de gestion de la mémoire. Peut être causé par un module PHP. Dans mon cas, l'installation d'APC a fonctionné. En théorie, d'autres paquets comme eAccelerator, etc. XDebug peut aider aussi. Ou, si vous avez ce genre de modules installés, essayez de les éteindre.

Answer 21

Je suis en train d'écrire une extension php et rencontre également ce problème. Quand j'appelle une fonction extern avec des paramètres compliqués de mon extension, cette erreur pop-up.

La raison est mon pas allouer de la mémoire pour un paramètre (char *) dans la fonction extern. Si vous écrivez même genre d'extension, s'il vous plaît faites attention à cela.

Answer 22

Pour moi, ce fut le ZendDebugger qui a provoqué la fuite de mémoire et cuased le memoryManager- crash.

je l'ai désactivé et je suis actuellement à la recherche d'une version plus récente. Si je ne peux pas trouver un, je vais passer à xdebug ...

Answer 23

Parce que je ne trouve une solution à ce que j'ai décidé de mettre à jour mon environnement LAMP. Je suis allé à Ubuntu 10.4 LTS avec PHP 5.3.x. Cela semble avoir arrêté le problème pour moi.

Answer 24

Dans mon cas, j'oubliais suivante dans le code:

);

J'ai joué et oublié dans le code ici et là - dans certains endroits que j'ai eu corruption tas, certains cas simplement faute seg « ol plaine:

[Wed Jun 08 17:23:21 2011] [notice] child pid 5720 exit signal Segmentation fault (11)

Je suis sur mac 10.6.7 et xampp.

Answer 25

Je l'ai aussi remarqué cette erreur et lors de l'exécution de l'ancien code SIGSEGV qui utilise « & » pour forcer explicitement les références lors de l'exécution en PHP 5.2 +.

Answer 26

Réglage

assert.active = 0 

dans le php.ini a aidé pour moi (il éteint affirmations de type dans la bibliothèque de php5UTF8 et zend_mm_heap corrupted est parti)

Answer 27

Pour moi, le problème a été écrasé démon memcached, comme PHP a été configuré pour stocker des informations de session dans memcached. Il mangeait cpu 100% et d'agir bizarre. Après problème de redémarrage memcached est passé.

Answer 28

Étant donné qu'aucun des autres réponses adressées, j'ai eu ce problème en php 5.4 quand je courais accidentellement une boucle infinie.

Answer 29

Certains des conseils qui peuvent aide quelqu'un

fedora 20, php 05.05.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'aide var_dummp () en fait pas une erreur, il a été placé juste pour le débogage et sera supprimé sur le code de production. Mais l'endroit est réel où zend_mm_heap est arrivé est la deuxième place.

Answer 30

J'étais en même situation ici, rien au-dessus aidé, et vérifier que je trouve plus au sérieux mon problème, il consiste à essayer ne meurent (en-tête ()) après l'envoi une sortie tampon, l'homme qui a fait cela dans le Code oublié sur les ressources CakePHP et n'a pas fait une sIMPLES "return $ this-> redirect ($ url)".

Essayer de réinventer le bien, ce fut le problème.

J'espère que cela se rapporte à quelqu'un d'aide!