All'improvviso ho avuto problemi con la mia applicazione che non avevo mai avuto prima. Ho deciso di controllare il registro degli errori di Apache e ho trovato un messaggio di errore che diceva "zend_mm_heap danneggiato". Cosa significa questo.

Sistema operativo: Fedora Core 8 Apache: 2.2.9 PHP: 5.2.6

Dopo molte prove ed errori, ho scoperto che se aumento il output_bufferingvalore nel file php.ini, questo errore scompare

Questo non è un problema che è necessariamente risolvibile modificando le opzioni di configurazione.

La modifica delle opzioni di configurazione a volte avrà un impatto positivo, ma può altrettanto facilmente peggiorare le cose o non fare nulla.

La natura dell'errore è questa:

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

Il codice sopra può essere compilato con:

gcc -g -o corrupt corrupt.c

Eseguendo il codice con valgrind puoi vedere molti errori di memoria, che culminano in un errore di segmentazione:

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

Se non lo sapevi, hai già capito che memè la memoria allocata in heap; L'heap si riferisce alla regione di memoria disponibile per il programma in fase di esecuzione, perché il programma lo ha esplicitamente richiesto (con malloc nel nostro caso).

Se giochi con il codice terribile, scoprirai che non tutte quelle dichiarazioni ovviamente errate provocano un errore di segmentazione (un errore fatale di terminazione).

Ho fatto esplicitamente quegli errori nel codice di esempio, ma gli stessi tipi di errori si verificano molto facilmente in un ambiente gestito dalla memoria: se un codice non mantiene il conteggio di una variabile (o qualche altro simbolo) nel modo corretto, ad esempio se è libero è troppo presto, un altro pezzo di codice potrebbe leggere dalla memoria già libera, se in qualche modo memorizza l'indirizzo sbagliato, un altro pezzo di codice potrebbe scrivere nella memoria non valida, potrebbe essere libero due volte ...

Questi non sono problemi che possono essere sottoposti a debug in PHP, richiedono assolutamente l'attenzione di uno sviluppatore interno.

Il corso di azione dovrebbe essere:

1. Apri una segnalazione di bug su http://bugs.php.net
   • Se hai un segfault, prova a fornire un backtrace
   • Includi tutte le informazioni di configurazione che sembrano appropriate, in particolare se stai utilizzando opcache includi il livello di ottimizzazione.
   • Continua a controllare la segnalazione di bug per gli aggiornamenti, potrebbero essere richieste ulteriori informazioni.
2. Se hai opcache caricato, disabilita le ottimizzazioni
   • Non sto scegliendo Opcache, è fantastico, ma alcune delle sue ottimizzazioni sono state conosciute per causare errori.
   • Se non funziona, anche se il tuo codice potrebbe essere più lento, prova prima a scaricare opcache.
   • Se una di queste modifiche o risolve il problema, aggiorna la segnalazione di bug che hai effettuato.
3. Disabilita tutte le estensioni non necessarie contemporaneamente.
   • Inizia ad abilitare tutte le tue estensioni individualmente, testando accuratamente dopo ogni modifica della configurazione.
   • Se trovi l'estensione del problema, aggiorna la tua segnalazione bug con maggiori informazioni.
4. Profitto.

Potrebbe non esserci alcun profitto ... Ho detto all'inizio, potresti essere in grado di trovare un modo per cambiare i sintomi facendo confusione con la configurazione, ma questo è estremamente incostante, e non aiuta la prossima volta che hai lo stesso zend_mm_heap corruptedmessaggio, ci sono solo tante opzioni di configurazione.

È davvero importante creare report di bug quando troviamo bug, non possiamo presumere che la prossima persona a colpirlo lo farà ... molto probabilmente, la risoluzione effettiva non è in alcun modo misteriosa, se rendi il persone giuste consapevoli del problema.

USE_ZEND_ALLOC

Se impostato USE_ZEND_ALLOC=0nell'ambiente, questo disabilita il gestore della memoria di Zend; Il gestore della memoria di Zend assicura che ogni richiesta abbia il proprio heap, che tutta la memoria sia libera alla fine di una richiesta ed è ottimizzata per l'allocazione di blocchi di memoria delle dimensioni giuste per PHP.

Disabilitarlo disabiliterà quelle ottimizzazioni, cosa ancora più importante probabilmente creerà perdite di memoria, poiché esiste un sacco di codice di estensione che si basa su Zend MM per liberare memoria per loro alla fine di una richiesta (tut, tut).

Potrebbe anche nascondere i sintomi, ma l'heap di sistema può essere danneggiato esattamente allo stesso modo dell'heap di Zend.

Può sembrare di essere più tolleranti o meno tolleranti, ma correggere la causa principale del problema, non ci riesce .

La possibilità di disabilitarlo affatto, è a beneficio degli sviluppatori interni; Non si dovrebbe mai distribuire PHP con Zend MM disabilitato.

Stavo ottenendo lo stesso errore in PHP 5.5 e aumentare il buffering dell'output non mi ha aiutato. Non stavo eseguendo APC, quindi non era questo il problema. Alla fine l'ho rintracciato in opcache , ho semplicemente dovuto disabilitarlo dal cli. C'era un'impostazione specifica per questo:

opcache.enable_cli=0

Una volta cambiato, l'errore zend_mm_heap danneggiato è scomparso.

Se sei su Linux box, prova questo dalla riga di comando

export USE_ZEND_ALLOC=0

Verificare la presenza di unset()s. Assicurati di non fare unset()riferimento ai $this(o equivalenti) nei distruttori e che quelli unset()nei distruttori non fanno scendere il conteggio dei riferimenti allo stesso oggetto a 0. Ho fatto qualche ricerca e ho scoperto che è ciò che di solito causa l'heap corruzione.

Esiste una segnalazione di bug PHP sull'errore danneggiato zend_mm_heap . Vedi il commento [2011-08-31 07:49 UTC] f dot ardelian at gmail dot comper un esempio su come riprodurlo.

Ho la sensazione che tutte le altre "soluzioni" (modifica php.ini, compilazione di PHP dal sorgente con meno moduli, ecc.) Nascondano il problema.

Per me nessuna delle risposte precedenti ha funzionato, fino a quando non ho provato:

opcache.fast_shutdown=0

Sembra funzionare finora.

Sto usando PHP 5.6 con PHP-FPM e Apache proxy_fcgi, se è importante ...

Nel mio caso, la causa di questo errore era che una delle matrici stava diventando molto grande. Ho impostato il mio script per ripristinare l'array ad ogni iterazione e questo ha risolto il problema.

Secondo il bug tracker, impostare opcache.fast_shutdown=0. Lo spegnimento rapido usa il gestore della memoria Zend per ripulire il suo casino, questo lo disabilita.

Non credo che ci sia una risposta qui, quindi aggiungerò la mia esperienza. Ho visto questo stesso errore insieme a segfaults httpd casuali. Questo era un server cPanel. Il sintomo in questione era che Apache ripristinava in modo casuale la connessione (nessun dato ricevuto in Chrome, o la connessione veniva ripristinata in Firefox). Erano apparentemente casuali - il più delle volte ha funzionato, a volte no.

Quando sono arrivato sulla scena, il buffering di output era OFF. Leggendo questo thread, che suggeriva il buffering dell'output, l'ho attivato (= 4096) per vedere cosa sarebbe successo. A questo punto, tutti hanno iniziato a mostrare gli errori. Questo era positivo, poiché l'errore era ora ripetibile.

Ho esaminato e ho iniziato a disabilitare le estensioni. Tra questi, un rivenditore, un pdo, un caricatore di ioni cubi e molti altri che sembravano sospetti, ma nessuno li aiutò.

Alla fine ho trovato l'estensione PHP cattiva come "homeloader.so", che sembra essere una sorta di modulo cPanel-easy-installer. Dopo la rimozione, non ho riscontrato altri problemi.

In quella nota, sembra che questo sia un messaggio di errore generico, quindi la tua media varierà con tutte queste risposte, la migliore linea d'azione che puoi intraprendere:

• Rendi l'errore ripetibile (quali condizioni?) Ogni volta
• Trova il fattore comune
• Disattiva selettivamente qualsiasi modulo PHP, opzione, ecc. (O, se sei di fretta, disabilitalo tutti per vedere se aiuta, quindi riattivali selettivamente fino a quando non si rompe di nuovo)
• Se ciò non aiuta, molte di queste risposte suggeriscono che potrebbe essere ripetuto il codice. Ancora una volta, la chiave è rendere l'errore ripetibile ogni richiesta in modo da poterlo restringere. Se sospetti che un pezzo di codice lo stia facendo, ancora una volta, dopo che l'errore è ripetibile, rimuovi semplicemente il codice fino a quando l'errore non si interrompe. Una volta che si ferma, sai che l'ultimo pezzo di codice che hai rimosso era il colpevole.

In mancanza di tutto quanto sopra, puoi anche provare cose come:

• Aggiornamento o ricompilazione di PHP. Spero che qualunque bug stia causando il tuo problema è stato corretto.
• Sposta il codice in un altro ambiente (di prova). Se questo risolve il problema, cosa è cambiato? opzioni php.ini? Versione PHP? eccetera...

In bocca al lupo.

Ho lottato con questo problema, per una settimana, ha funzionato per me o almeno così sembra

Nel php.inifare questi cambiamenti

report_memleaks = Off  
report_zend_debug = 0  

Il mio set up è

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

Questo non ha funzionato.

Quindi ho provato a usare uno script di benchmark e ho provato a registrare dove lo script era in sospeso. Ho scoperto che poco prima dell'errore è stato istanziato un oggetto php e ci sono voluti più di 3 secondi per completare ciò che l'oggetto avrebbe dovuto fare, mentre nei cicli precedenti ci sono voluti max 0,4 secondi. Ho eseguito questo test parecchie volte e ogni volta lo stesso. Invece di creare un nuovo oggetto ogni volta, ho pensato (qui c'è un lungo loop), avrei dovuto riutilizzare l'oggetto. Finora ho testato lo script più di una dozzina di volte e gli errori di memoria sono scomparsi!

Cerca qualsiasi modulo che utilizza il buffering e disabilitalo selettivamente.

Sto eseguendo PHP 5.3.5 su CentOS 4.8 e dopo aver fatto ciò ho trovato che acceleratore aveva bisogno di un aggiornamento.

Ho avuto questo problema anche su un server di mia proprietà e la causa principale era APC. Ho commentato l'estensione "apc.so" nel file php.ini, ricaricato Apache e i siti sono tornati indietro.

Ho provato tutto sopra e zend.enable_gc = 0- l'unica impostazione di configurazione, che mi ha aiutato.

PHP 5.3.10-1ubuntu3.2 con Suhosin-Patch (cli) (costruito: 13 giugno 2012 17:19:58)

Ho riscontrato questo errore utilizzando il driver Mongo 2.2 per PHP:

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

^^ NON FUNZIONA

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

^^ FUNZIONA! (?!)

Su PHP 5.3, dopo molte ricerche, questa è la soluzione che ha funzionato per me:

Ho disabilitato la garbage collection di PHP per questa pagina aggiungendo:

<? gc_disable(); ?>

alla fine della pagina problematica, che ha fatto scomparire tutti gli errori.

fonte .

Penso che molte ragioni possano causare questo problema. E nel mio caso, nominerò 2 classi con lo stesso nome e uno proverà a caricarne un altro.

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

E causa questo problema nel mio caso.

(Usando il framework laravel, eseguendo php artisan db: seed in real)

Ho avuto lo stesso problema e quando avevo un IP errato per session.save_path per sessioni memcached. La modifica dell'IP corretto ha risolto il problema.

Se si utilizzano tratti e il tratto viene caricato dopo la classe (ad esempio il caso del caricamento automatico) è necessario caricare il tratto in anticipo.

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

Nota: questo errore è molto casuale; a causa della sua natura.

Per me il problema era usare pdo_mysql. La query ha restituito risultati nel 1960. Ho provato a restituire 1900 dischi e funziona. Quindi il problema è pdo_mysql e array troppo grande. Ho riscritto la query con l'estensione mysql originale e ha funzionato.

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

Apache non ha segnalato errori precedenti.

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 corrotto" significa problemi con la gestione della memoria. Può essere causato da qualsiasi modulo PHP. Nel mio caso l'installazione di APC ha funzionato. In teoria, potrebbero essere utili anche altri pacchetti come eAccelerator, XDebug ecc. Oppure, se hai installato quel tipo di moduli, prova a spegnerli.

Sto scrivendo un'estensione php e riscontro anche questo problema. Quando chiamo una funzione extern con parametri complicati dalla mia estensione, compare questo errore.

Il motivo è che non sto allocando memoria per un parametro (char *) nella funzione extern. Se stai scrivendo lo stesso tipo di estensione, presta attenzione a questo.

Per me, è stato ZendDebugger a causare la perdita di memoria e ha provocato l'arresto anomalo del MemoryManager.

L'ho disabilitato e attualmente sto cercando una versione più recente. Se non riesco a trovarne uno, passerò a xdebug ...

Poiché non ho mai trovato una soluzione a questo, ho deciso di aggiornare il mio ambiente LAMP. Sono andato su Ubuntu 10.4 LTS con PHP 5.3.x. Questo sembra aver fermato il problema per me.

Nel mio caso, ho dimenticato quanto segue nel codice:

);

Ho giocato e l'ho dimenticato nel codice qua e là - in alcuni punti ho avuto un sacco di corruzione, in alcuni casi semplicemente colpa mia:

[Mer 08 giu 17:23:21 2011] [avviso] figlio pid 5720 segnale di uscita Errore di segmentazione (11)

Sono su Mac 10.6.7 e xampp.

Ho anche notato questo errore e SIGSEGV durante l'esecuzione del vecchio codice che utilizza '&' per forzare esplicitamente i riferimenti durante l'esecuzione in PHP 5.2+.

Ambientazione

assert.active = 0 

in php.ini mi ha aiutato (ha disattivato le asserzioni di tipo in php5UTF8libreria e zend_mm_heap corruptedse n'è andato)

Per me il problema è stato l'arresto anomalo del demone memcached, in quanto PHP è stato configurato per memorizzare le informazioni sulla sessione in memcached. Stava mangiando 100% CPU e si comportava in modo strano. Dopo che il problema di riavvio memcached è andato.

Dato che nessuna delle altre risposte ha risolto il problema, ho riscontrato questo problema in php 5.4 quando ho eseguito accidentalmente un ciclo infinito.

Alcuni consigli che possono aiutare qualcuno

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 () in realtà non è un errore, è stato inserito solo per il debug e verrà rimosso sul codice di produzione. Ma il luogo reale in cui è accaduto zend_mm_heap è il secondo posto.

Ero nella stessa situazione qui, niente sopra aiutato, e controllando più seriamente trovo il mio problema, consiste nel provare a morire (header ()) dopo aver inviato un output al buffer, l'uomo che ha fatto questo nel Codice ha dimenticato le risorse di CakePHP e non ha fatto un semplice "return $ this-> redirect ($ url)".

Cercando di reinventare il pozzo, questo era il problema.

Spero che questo possa aiutare qualcuno!