it-swarm.com.de

Was bedeutet "zend_mm_heap beschädigt"?

Ich hatte plötzlich Probleme mit meiner Bewerbung, die ich noch nie hatte. Ich beschloss, das Fehlerprotokoll des Apache zu überprüfen, und fand eine Fehlermeldung mit dem Hinweis "zend_mm_heap beschädigt". Was bedeutet das.

Betriebssystem: Fedora Core 8 Apache: 2.2.9 PHP: 5.2.6

115
bkulyk

Nach langem Ausprobieren stellte ich fest, dass dieser Fehler behoben wird, wenn ich den output_buffering-Wert in der Datei php.ini erhöht

50
dsmithers

Ich habe diesen Fehler unter PHP 5.5 erhalten und das Erhöhen der Ausgabepufferung hat nicht geholfen. Ich habe auch nicht APC ausgeführt, also war das nicht das Problem. Ich habe es schließlich nach opcache ausfindig gemacht, ich musste es einfach aus dem CLI deaktivieren. Dafür gab es eine spezielle Einstellung: 

opcache.enable_cli=0

Sobald der zend_mm_heap-Fehler gewechselt wurde, verschwand der Fehler. 

44
Justin MacLeod

Wenn Sie eine Linux-Box verwenden, versuchen Sie es in der Befehlszeile 

export USE_ZEND_ALLOC=0
40
Hittz

Dies ist kein Problem, das notwendigerweise durch Ändern der Konfigurationsoptionen gelöst werden kann. 

Das Ändern von Konfigurationsoptionen wirkt sich manchmal positiv aus, kann jedoch ebenso leicht die Situation verschlimmern oder gar nichts tun.

Die Art des Fehlers lautet:

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

Der obige Code kann wie folgt kompiliert werden:

gcc -g -o corrupt corrupt.c

Wenn Sie den Code mit valgrind ausführen, können Sie viele Speicherfehler sehen, die zu einem Segmentierungsfehler führen:

[email protected]:/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: [email protected]@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: [email protected]@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

Wenn Sie es nicht wussten, haben Sie bereits herausgefunden, dass mem Heapspeicher ist. Der Heap bezieht sich auf den Speicherbereich, der dem Programm zur Laufzeit zur Verfügung steht, da das Programm diesen explizit angefordert hat (in unserem Fall mit malloc).

Wenn Sie mit dem schrecklichen Code herumspielen, werden Sie feststellen, dass nicht alle dieser offensichtlich falschen Anweisungen zu einem Segmentierungsfehler (einem fatalen Beendigungsfehler) führen.

Ich habe diese Fehler im Beispielcode explizit gemacht, aber die gleichen Arten von Fehlern treten sehr leicht in einer vom Speicher verwalteten Umgebung auf: Wenn ein Code beispielsweise den Refcount einer Variablen (oder eines anderen Symbols) nicht auf die richtige Weise verwaltet Wenn es zu früh ist, kann ein anderer Code aus dem bereits freigegebenen Speicher gelesen werden. Wenn die Adresse irgendwie falsch gespeichert wird, kann ein anderer Code in den ungültigen Speicher geschrieben werden. Er kann zweimal freigegeben werden.

Dies sind keine Probleme, die in PHP debugiert werden können, sie erfordern die Aufmerksamkeit eines internen Entwicklers.

Die Vorgehensweise sollte sein:

  1. Öffnen Sie einen Fehlerbericht unter http://bugs.php.net
    • Wenn Sie einen Segfault haben, versuchen Sie einen backtrace
    • Fügen Sie so viele Konfigurationsinformationen hinzu, wie es angemessen erscheint, insbesondere wenn Sie die Optimierungsstufe opcache include verwenden.
    • Überprüfen Sie den Fehlerbericht regelmäßig auf Aktualisierungen. Möglicherweise werden weitere Informationen angefordert.
  2. Wenn Sie Opcache geladen haben, deaktivieren Sie die Optimierungen
    • Ich habe mich nicht für Opcache entschieden, es ist großartig, aber es ist bekannt, dass einige Optimierungen Fehler verursachen.
    • Wenn dies nicht funktioniert, auch wenn der Code langsamer ist, entladen Sie zunächst den Opcache.
    • Wenn einer dieser Punkte das Problem ändert oder behebt, aktualisieren Sie den von Ihnen gemachten Fehlerbericht.
  3. Deaktivieren Sie all unnötige Erweiterungen auf einmal .
    • Aktivieren Sie alle Erweiterungen einzeln und testen Sie sie nach jeder Konfigurationsänderung gründlich.
    • Wenn Sie die Problemerweiterung finden, aktualisieren Sie Ihren Fehlerbericht mit weiteren Informationen.
  4. Profitieren.

Es kann keinen Gewinn geben ... Ich sagte zu Beginn, Sie könnten möglicherweise einen Weg finden, um Ihre Symptome zu ändern, indem Sie die Konfiguration durcheinander bringen. Dies ist jedoch ein absoluter Zufall und hilft beim nächsten Mal nicht weiter Dieselbe zend_mm_heap corrupted-Nachricht, es gibt nur so viele Konfigurationsoptionen.

Es ist sehr wichtig, dass wir Fehlerberichte erstellen, wenn wir Fehler finden. Wir können nicht davon ausgehen, dass die nächste Person, die den Fehler trifft, dies tun wird Richtige Leute, die sich des Problems bewusst sind.

USE_ZEND_ALLOC

Wenn Sie in der Umgebung USE_ZEND_ALLOC=0 einstellen, wird der eigene Speichermanager von Zend deaktiviert. Der Speichermanager von Zend stellt sicher, dass jede Anforderung über einen eigenen Heap verfügt, dass der gesamte Speicher am Ende einer Anforderung frei ist und für die Zuweisung von Speicherblöcken optimiert ist, genau die richtige Größe für PHP.

Durch das Deaktivieren werden diese Optimierungen deaktiviert. Wichtiger ist, dass wahrscheinlich Speicherverluste entstehen, da es eine Menge Erweiterungscode gibt, der darauf beruht, dass der Zend MM am Ende einer Anforderung Speicherplatz freigibt (tut, tut).

Es kann auch hide die Symptome sein, aber der System-Heap kann genauso wie der von Zend beschädigt werden. 

Es scheint toleranter oder weniger tolerant zu sein, aber beheben Sie die Hauptursache des Problems, kann nicht.

Die Möglichkeit, es überhaupt zu deaktivieren, ist für interne Entwickler von Vorteil. Sie sollten niemals mit PHP implementieren, wenn Zend MM deaktiviert ist.

34
Joe Watkins

Auf unset()s prüfen. Stellen Sie sicher, dass Sie keine unset()-Verweise auf $this (oder Äquivalente) in Destruktoren verwenden und dass unset()s in Destruktoren nicht dazu führen, dass die Referenzzählung auf dasselbe Objekt auf 0 fällt die Haufen Korruption.

Es gibt einen PHP Fehlerbericht über den beschädigten zend_mm_heap - Fehler. Siehe den Kommentar [2011-08-31 07:49 UTC] f dot ardelian at gmail dot com für ein Beispiel, wie man es reproduzieren kann.

Ich habe das Gefühl, dass alle anderen "Lösungen" (php.ini ändern, PHP aus dem Quellcode mit weniger Modulen kompilieren usw.) das Problem einfach verbergen.

23
f.ardelian

In meinem Fall war die Ursache für diesen Fehler, dass eines der Arrays sehr groß wurde. Ich habe mein Skript so eingestellt, dass das Array bei jeder Iteration zurückgesetzt wird. 

7
Piotr

Stellen Sie gemäß dem Bug-Tracker opcache.fast_shutdown=0 ein. Beim schnellen Herunterfahren wird der Zend-Speichermanager verwendet, um das Durcheinander zu beseitigen.

5
Taco de Wolff

Für mich funktionierte keine der vorherigen Antworten, bis ich es versuchte:

opcache.fast_shutdown=0

Das scheint soweit zu klappen. 

Ich verwende PHP 5.6 mit PHP-FPM und Apache proxy_fcgi, wenn das wichtig ist ...

5
Jesús Carrera

Ich habe mit diesem Thema eine Woche lang gerungen. Das hat für mich funktioniert, zumindest scheint es so 

Nehmen Sie diese Änderungen in php.ini vor 

report_memleaks = Off  
report_zend_debug = 0  

Mein Setup ist 

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

Das hat nicht funktioniert. 

Also versuchte ich es mit einem Benchmark-Skript und nahm die Aufnahme auf, wo das Skript aufgehängt war ... Ich entdeckte, dass kurz vor dem Fehler ein PHP-Objekt instanziiert wurde, und es dauerte mehr als 3 Sekunden, bis das Objekt fertiggestellt war tun, während es in den vorherigen Schleifen maximal 0,4 Sekunden gedauert hat. Ich habe diesen Test einige Male durchgeführt und jedes Mal das gleiche. Ich dachte, anstatt jedes Mal ein neues Objekt zu erstellen (hier ist eine lange Schleife), sollte ich das Objekt wiederverwenden. Ich habe das Skript mehr als ein Dutzend Mal getestet und die Speicherfehler sind verschwunden!

4
sam

Ich glaube nicht, dass es hier eine Antwort gibt, also werde ich meine Erfahrung hinzufügen. Ich habe den gleichen Fehler zusammen mit zufälligen httpd-Fehlern gesehen. Dies war ein cPanel-Server. Das fragliche Symptom war, dass Apache die Verbindung nach dem Zufallsprinzip zurücksetzte (in Chrome wurden keine Daten empfangen, in Firefox wurde die Verbindung zurückgesetzt). Diese waren scheinbar zufällig - meistens funktionierte es, manchmal nicht.

Als ich in der Szene ankam, war die Pufferung ausgeschaltet. Beim Lesen dieses Threads, der auf Ausgabepufferung hindeutete, habe ich ihn aktiviert (= 4096), um zu sehen, was passieren würde. Zu diesem Zeitpunkt zeigten sie alle die Fehler an. Das war gut so, dass der Fehler nun wiederholbar war.

Ich habe angefangen, Erweiterungen zu deaktivieren. Unter ihnen waren eaccellerator, pdo, ioncube loader und vieles, was sah verdächtig aus, aber nichts half.

Endlich fand ich die freche Erweiterung PHP als "homeloader.so", eine Art cPanel-easy-installer-Modul. Nach dem Entfernen sind keine weiteren Probleme aufgetreten.

In diesem Sinne handelt es sich anscheinend um eine allgemeine Fehlermeldung, sodass Ihr Kilometerstand mit all diesen Antworten variiert. Dies ist die beste Vorgehensweise, die Sie ergreifen können:

  • Machen Sie den Fehler jedes Mal reproduzierbar (unter welchen Bedingungen?)
  • Finden Sie den gemeinsamen Faktor
  • Deaktivieren Sie selektiv alle PHP Module, Optionen usw. (oder deaktivieren Sie, wenn Sie in Eile sind, alle, um zu sehen, ob es hilft, und aktivieren Sie sie selektiv wieder, bis es wieder kaputt geht).
  • Wenn dies nicht hilft, deuten viele dieser Antworten darauf hin, dass der Code erneut verwendet werden könnte. Wieder ist der Schlüssel, um den Fehler wiederholbar zu machen jede Anfrage, damit Sie ihn eingrenzen können. Wenn Sie vermuten, dass ein Teil des Codes dies tut, entfernen Sie den Code erneut, nachdem der Fehler wiederholt werden kann, bis der Fehler behoben ist. Sobald es aufhört, wissen Sie, dass der letzte Code, den Sie entfernt haben, der Schuldige war.

Wenn Sie alle oben genannten Punkte nicht einhalten, können Sie auch Folgendes ausprobieren:

  • Aktualisieren oder erneutes Kompilieren von PHP. Ich hoffe, der Fehler, der Ihr Problem verursacht, ist behoben.
  • Verschieben Sie Ihren Code in eine andere (Test-) Umgebung. Wenn dies das Problem behebt, was hat sich geändert? Optionen für php.ini? PHP Version? usw...

Viel Glück.

3
A.B. Carroll

Suchen Sie nach einem Modul, das Pufferung verwendet, und deaktivieren Sie es selektiv.

Ich führe PHP 5.3.5 auf CentOS 4.8 aus und danach fand ich, dass eaccelerator ein Upgrade benötigte.

2
Scott Davey

Ich hatte dieses Problem gerade auf einem Server, den ich besitze, und die Hauptursache war APC. Ich habe die Erweiterung "apc.so" in der php.ini-Datei auskommentiert, Apache neu geladen, und die Websites kamen sofort wieder hoch.

2
Vance Lucas

Auf PHP 5.3, nach langem Suchen, ist dies die Lösung, die für mich funktioniert hat:

Ich habe die PHP - Garbage Collection für diese Seite durch Hinzufügen von deaktiviert:

<? gc_disable(); ?>

bis zum Ende der problematischen Seite, die alle Fehler verschwinden ließ. 

Quelle .

2
Kuf

Ich denke, dass viele Gründe dieses Problem verursachen können. In meinem Fall nenne ich 2 Klassen denselben Namen, und eine wird versuchen, eine andere zu laden. 

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

Und es verursacht dieses Problem in meinem Fall.

(Mit Laravel-Framework, PHP-Handwerker db: Seed in real ausführen)

2
Yarco

Ich hatte diesen Fehler beim Verwenden des Mongo 2.2-Treibers für PHP:

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

^^ FUNKTIONIERT NICHT

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

^^ FUNKTIONIERT! (?!)

2
hernanc

Ich habe alles oben und zend.enable_gc = 0 ausprobiert - die einzige Konfigeinstellung, die mir geholfen hat.

PHP 5.3.10-1ubuntu3.2 mit Suhosin-Patch (cli) (erstellt am 13. Juni 2012 um 17:19:58 Uhr) 

2
Bethrezen

Ich schreibe eine PHP-Erweiterung und stoße auch auf dieses Problem. Wenn ich eine externe Funktion mit komplizierten Parametern von meiner Erweiterung aus aufrufe, wird dieser Fehler angezeigt. 

Der Grund ist, dass ich keinen Speicher für einen Parameter (char *) in der externen Funktion reserviert. Wenn Sie dieselbe Art von Erweiterung schreiben, achten Sie bitte darauf.

1
cedricliang

Wenn Sie Merkmale verwenden und das Merkmal nach der Klasse geladen wird (dh bei automatischem Laden), müssen Sie das Merkmal zuvor laden.

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

Hinweis: Dieser Fehler ist sehr zufällig. wegen seiner natur. 

1
srcspider

Für mich war das Problem die Verwendung von pdo_mysql. Abfrage ergab 1960 Ergebnisse. Ich habe versucht, 1900 Datensätze zurückzugeben, und es funktioniert. Das Problem ist also pdo_mysql und ein zu großes Array. Ich habe die Abfrage mit der ursprünglichen MySQL-Erweiterung neu geschrieben und es hat funktioniert.

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

Apache hat keine vorherigen Fehler gemeldet. 

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)
1
broadband

Ich hatte das gleiche Problem und als ich eine falsche IP für session.save_path für Memcached-Sitzungen hatte. Das Ändern der IP-Adresse in die richtige IP hat das Problem behoben. 

1
Travis Derouin

"zend_mm_heap fehlerhaft" bedeutet Probleme bei der Speicherverwaltung. Kann durch ein beliebiges PHP Modul verursacht werden. Theoretisch können auch andere Pakete wie eAccelerator, XDebug usw. hilfreich sein. Wenn Sie solche Module installiert haben, schalten Sie sie aus.

1
Muto

Viele Leute erwähnen die Deaktivierung von XDebug, um das Problem zu lösen. Dies ist offensichtlich in vielen Fällen nicht praktikabel, da es aus einem bestimmten Grund aktiviert ist - um Ihren Code zu debuggen.

Ich hatte das gleiche Problem und bemerkte, dass der Fehler nicht mehr auftrat, wenn ich in meinem IDE (PhpStorm 2019.1 EAP) nicht mehr auf XDebug-Verbindungen wartete.

Der eigentliche Fix bestand für mich darin, vorhandene Haltepunkte zu entfernen.

Eine Möglichkeit, dass dies ein gültiger Fix ist, besteht darin, dass PhpStorm manchmal nicht so gut darin ist, Haltepunkte zu entfernen, die nicht mehr auf gültige Codezeilen verweisen, nachdem Dateien extern geändert wurden (z. B. durch git).

Bearbeiten: Den entsprechenden Fehlerbericht im xdebug-Issue-Tracker gefunden: https://bugs.xdebug.org/view.php?id=1647

0
Dejan Lukić

Hatte zend_mm_heap corrupted zusammen mit child pid ... exit signal Segmentation fault auf einem Debian-Server, der auf Jessie aktualisiert wurde. Nach langen Untersuchungen stellte sich heraus, dass XCache installiert war, da die Zend-Engine allgemein verfügbar war.

nach apt-get remove php5-xcache und service Apache2 restart sind die Fehler verschwunden.

0
Martin Seitl

Einige Tipps, die einem helfen können

Fedora 20, ph 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;
    }
}

mit var_dummp () ist es eigentlich kein Fehler, es wurde nur zum Debuggen bereitgestellt und wird im Produktionscode entfernt. Der wirkliche Ort, an dem zend_mm_heap stattgefunden hat, ist der zweite Platz. 

0
lexand

Ich befand mich in derselben Situation, nichts hat geholfen, und ernsthafter überprüfend finde ich mein Problem. Es besteht darin, dass Sie versuchen, zu sterben (header ()), nachdem Sie einige Ausgaben in den Puffer geschickt haben und machte kein simples "return $ this-> redirect ($ url)".

Der Versuch, den Brunnen neu zu erfinden, war das Problem.

Ich hoffe das jemandem helfen kann!

Für mich war es RabbitMq mit Xdebug in PHPStorm, also> Einstellungen/Sprache und Frameworks/PHP/Debug/Xdebug> "Externe Verbindungen akzeptieren" aufheben.

0

Da keine der anderen Antworten darauf angesprochen wurde, hatte ich dieses Problem in PHP 5.4, als ich versehentlich eine Endlosschleife ausführte.

0
Trenton Maki

Für mich war es der ZendDebugger, der den Speicherverlust verursachte und den MemoryManager zum Absturz brachte.

Ich habe es deaktiviert und suche derzeit nach einer neueren Version. Wenn ich keinen finden kann, wechsle ich zu xdebug ...

0
Structed

Bei der Gelegenheit, dass jemand anderes dieses Problem in der gleichen Weise hat wie ich, dachte ich, ich würde die Lösung anbieten, die für mich funktionierte.

Ich habe php unter Windows auf einem anderen Laufwerk als meinem Systemlaufwerk installiert ( H: ). 

In meiner php.ini-Datei wurde der Wert mehrerer verschiedener Dateisystemvariablen wie \path\to\directory geschrieben. Dies hätte gut funktioniert, wenn sich meine Installation auf C: befunden hätte.

Ich musste den Wert in H:\path\to\directory ändern. Durch Hinzufügen des Laufwerkbuchstabens an verschiedenen Stellen in meiner php.ini-Datei wurde das Problem sofort behoben. Ich habe auch sichergestellt (obwohl ich denke, dass dies nicht notwendig ist), um dasselbe Problem in meinem PEAR config zu beheben - da mehrere Variablenwerte den Laufwerksbuchstaben dort ebenfalls ausschließen.

0
dgo

Am 13. November 2014 wurde in PHP ein Fehler behoben:

Fehler # 68365 behoben (zend_mm_heap nach Speicherüberlauf in zend_hash_copy beschädigt).

Dieses wurde in den Versionen 5.4.35, 5.5.19 und 5.6.3 aktualisiert. In meinem Fall, als ich von Ubuntus offiziellem Trusty-Paket (5.5.9 + dfsg-1ubuntu4.14) auf die Version 5.5.30 von Ondrej Sury umgestellt bin, ist das Problem nicht mehr vorhanden. Keine der anderen Lösungen funktionierte für mich, und ich wollte Opcache nicht deaktivieren oder Fehler unterdrücken, da dies tatsächlich zu Fehlfunktionen führte (500 Antworten).

Ubuntu 14.04 LTS:

export LANG=C.UTF-8       # May not be required on your system
add-apt-repository ondrej/php5
apt-get update
apt-get upgrade
0
ColinM

Viele der Antworten sind alt. Für mich (php 7.0.10 über Ondrej Sury's PPA auf Ubuntu 14.04 und 16.04) scheint das Problem in APC zu liegen. Ich habe Hunderte von kleinen Datenbits mit apc_fetch () usw. im Cache gespeichert, und wenn ich einen Teil des Caches ungültig mache, würde ich den Fehler erhalten. Umgehung bestand darin, auf dateisystembasiertes Caching umzusteigen.

Weitere Informationen zu github https://github.com/oerdnj/deb.sury.org/issues/452#issuecomment-245475283

0
Steve

Für mich war das Problem mit dem Memcached-Daemon abgestürzt, da PHP so konfiguriert wurde, dass Sitzungsinformationen in Memcached gespeichert werden. Es war 100% ige CPU und wirkte komisch. Nach dem Neustart von memcached ist das Problem behoben.

0

In meinem Fall habe ich Folgendes im Code vergessen:

);

Ich habe herumgespielt und im Code hier und da vergessen - an einigen Stellen habe ich Haufen-Korruption bekommen, in einigen Fällen einfach nur Ol-Seg-Fehler:

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

Ich bin auf Mac 10.6.7 und XAMPP.

0
dsomnus

Ich habe auch diesen Fehler und die SIGSEGV-Fehler bemerkt, als ich alten Code ausführte, der explizit Referenzen mit "&" erzwingt, während er in PHP 5.2+ ausgeführt wird.

0
Phillip Whelan

Da ich dazu keine Lösung gefunden habe, habe ich mich entschlossen, meine LAMP-Umgebung zu aktualisieren. Ich bin mit PHP 5.3.x zu Ubuntu 10.4 LTS gegangen. Dies scheint das Problem für mich gestoppt zu haben.

0
bkulyk

Rahmen 

assert.active = 0 

in php.ini hat mir geholfen (es wurden Typ-Assertions in der php5UTF8-Bibliothek deaktiviert und zend_mm_heap corrupted ging weg)

0
Vasiliy

Durchsuchen Sie Ihren Code wirklich nach einem stillen Fehler. In meiner Symfony-App wurde der Fehler zend_mm_heap beschädigt, nachdem ein Block aus einer Zweigvorlagenvorlage entfernt wurde. Es wurde kein Fehler ausgegeben.

0
hipnosis