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

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

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

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.

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

export USE_ZEND_ALLOC=0

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.

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

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.

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.

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.

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!

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.

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.

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)

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

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 .

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)

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.

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.

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)

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

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.

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

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.

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.

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

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)

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.

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.

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.

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!