Co oznacza „zend_mm_heap uszkodzony”?

126

Nagle mam problemy z moją aplikacją, których nigdy wcześniej nie miałem. Zdecydowałem się sprawdzić dziennik błędów Apache i znalazłem komunikat o błędzie „zend_mm_heap uszkodzony”. Co to znaczy.

System operacyjny: Fedora Core 8 Apache: 2.2.9 PHP: 5.2.6

bkulyk
źródło
2
Kiedyś USE_ZEND_ALLOC=0pobierałem ślad stosu w dzienniku błędów I znalazłem błąd /usr/sbin/httpd: corrupted double-linked list, dowiedziałem się, że komentowanie opcache.fast_shutdown=1działało dla mnie.
Spidfire
Tak, to samo tutaj. Zobacz także kolejny raport poniżej stackoverflow.com/a/35212026/35946
lkraav
Miałem to samo, używając Laravel. Wstawiłem klasę do konstruktora innej klasy. Klasa, którą wstrzykiwałem, wstrzykiwała klasę, do której została wstrzyknięta, w zasadzie tworząc cykliczne odwołanie, powodując problem ze stertą.
Thomas
1
Zrestartuj serwer Apache, aby uzyskać najszybsze i tymczasowe rozwiązania :)
Leopathu,

Odpowiedzi:

52

Po wielu próbach i błędach stwierdziłem, że jeśli output_bufferingzwiększę wartość w pliku php.ini, ten błąd zniknie

dsmithers
źródło
59
Zwiększenie do czego? Dlaczego ta zmiana miałaby spowodować zniknięcie tego błędu?
JDS
2
@JDS ta odpowiedź pomaga wyjaśnić, czym jest buforowanie_wyjściowe i dlaczego jego zwiększenie może pomóc stackoverflow.com/a/2832179/704803
andrewtweber
8
@andrewtweber Wiem, co to jest ob, zastanawiałem się nad konkretnymi szczegółami, które zostały pominięte w odpowiedzi dsmithers, ponieważ otrzymywałem ten sam komunikat o błędzie co op. Do zamknięcia: okazało się, że moim problemem było źle skonfigurowane ustawienie dotyczące memcached. W każdym razie dzięki!
JDS
@JDS co źle skonfigurowane ustawienie?
Kyle Cronin
3
@KyleCronin nasza platforma usługowa wykorzystuje Memcache w produkcji. Jednak niektóre pojedyncze przypadki - nieprodukcyjne / piaskownica, jednorazowe zakupy klientów - nie używają memcache. W tym drugim przypadku miałem jednorazowo skopiowaną konfigurację z produkcji do klienta, a konfiguracja memcache wskazywała na identyfikator URI serwera memcache, który nie był dostępny w tym środowisku. Usunąłem linię i wyłączyłem memcache w aplikacji, a problem zniknął. Krótko mówiąc, bardzo specyficzny problem napotkany w określonym środowisku, który może nie mieć ogólnego zastosowania. Ale skoro pytałeś ...
JDS
47

Nie jest to problem, który można koniecznie rozwiązać poprzez zmianę opcji konfiguracyjnych.

Zmiana opcji konfiguracji będzie czasami miała pozytywny wpływ, ale równie łatwo może pogorszyć sytuację lub w ogóle nic nie robić.

Natura błędu jest następująca:

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

Powyższy kod można skompilować za pomocą:

gcc -g -o corrupt corrupt.c

Wykonując kod za pomocą valgrind można zobaczyć wiele błędów pamięci, których kulminacją jest błąd segmentacji:

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

Jeśli nie wiedziałeś, już zorientowałeś się, że memjest to pamięć przydzielona na stos; Sterta odnosi się do obszaru pamięci dostępnego dla programu w czasie wykonywania, ponieważ program jawnie go zażądał (w naszym przypadku z malloc).

Jeśli będziesz bawić się okropnym kodem, okaże się, że nie wszystkie z tych oczywiście niepoprawnych instrukcji powodują błąd segmentacji (krytyczny błąd zakończenia).

Jawnie popełniłem te błędy w przykładowym kodzie, ale te same rodzaje błędów zdarzają się bardzo łatwo w środowisku zarządzanym pamięcią: jeśli jakiś kod nie obsługuje liczby referencyjnej zmiennej (lub innego symbolu) we właściwy sposób, na przykład jeśli zwolni to za wcześnie, inny fragment kodu może odczytać z już wolnej pamięci, jeśli w jakiś sposób zapisze nieprawidłowy adres, inny fragment kodu może zapisać do niewłaściwej pamięci, może być zwolniony dwukrotnie ...

Nie są to problemy, które można debugować w PHP, absolutnie wymagają one uwagi wewnętrznego programisty.

Sposób postępowania powinien być:

  1. Otwórz raport o błędzie na http://bugs.php.net
    • Jeśli masz segfault, spróbuj podać ślad
    • Uwzględnij tyle informacji konfiguracyjnych, ile wydaje się właściwe, w szczególności, jeśli używasz poziomu optymalizacji dołączania opcache.
    • Sprawdzaj raport o błędzie pod kątem aktualizacji, możesz poprosić o więcej informacji.
  2. Jeśli załadowałeś opcache, wyłącz optymalizacje
    • Nie czepiam się opcache, jest świetny, ale niektóre z jego optymalizacji są znane z powodowania błędów.
    • Jeśli to nie zadziała, nawet jeśli twój kod może być wolniejszy, spróbuj najpierw zwolnić opcache.
    • Jeśli któraś z tych zmian lub rozwiąże problem, zaktualizuj zgłoszony błąd.
  3. Wyłącz wszystkie niepotrzebne rozszerzenia jednocześnie.
    • Zacznij włączać wszystkie rozszerzenia indywidualnie, dokładnie testując po każdej zmianie konfiguracji.
    • Jeśli znajdziesz rozszerzenie powodujące problem, zaktualizuj swój raport o błędzie, podając więcej informacji.
  4. Zysk.

Może nie być żadnego zysku ... Powiedziałem na początku, że możesz być w stanie znaleźć sposób na zmianę swoich objawów, mieszając konfigurację, ale jest to bardzo trafione i chybione i nie pomaga następnym razem ta sama zend_mm_heap corruptedwiadomość, jest tylko tyle opcji konfiguracyjnych.

Naprawdę ważne jest, abyśmy tworzyli raporty o błędach, gdy znajdziemy błędy, nie możemy zakładać, że zrobi to następna osoba, która trafi błąd ... bardziej prawdopodobne, że rzeczywista rozdzielczość nie jest w żaden sposób tajemnicza, jeśli zrobisz właściwi ludzie świadomi problemu.

USE_ZEND_ALLOC

Jeśli ustawisz USE_ZEND_ALLOC=0w środowisku, wyłącza to własnego menedżera pamięci Zend; Menedżer pamięci Zend zapewnia, że ​​każde żądanie ma własną stertę, że cała pamięć jest zwolniona na końcu żądania i jest zoptymalizowany pod kątem przydzielania fragmentów pamięci o rozmiarze odpowiednim dla PHP.

Wyłączenie go wyłączy te optymalizacje, co ważniejsze, prawdopodobnie spowoduje wycieki pamięci, ponieważ istnieje wiele kodów rozszerzeń, które zależą od Zend MM, aby zwolnić pamięć dla nich pod koniec żądania (tut, tut).

Może również ukryć objawy, ale sterta systemowa może zostać uszkodzona dokładnie w taki sam sposób, jak sterta Zend.

To może wydawać się być bardziej tolerancyjne lub mniej tolerancyjny, ale ustalić przyczynę problemu, to nie mogę .

Możliwość wyłączenia go w ogóle jest korzystna dla programistów wewnętrznych; Nigdy nie powinieneś wdrażać PHP z wyłączonym Zend MM.

Joe Watkins
źródło
Więc podstawowym problemem może być, której wersji PHP używasz?
Ishmael
@Ishmael Tak, a także wersje wszystkich rozszerzeń, ponieważ ostrzeżenie może wynikać z rozszerzenia.
biskup
2
Ta odpowiedź wydaje mi się najlepsza. Osobiście kilka razy doświadczyłem problemu i zawsze był on związany z wadliwym rozszerzeniem (w moim przypadku z biblioteką pisowni Enchant). Poza samym php, może to być również złe środowisko (niezgodność wersji lib, złe zależności itp.)
Fractalizer
1
Zdecydowanie najlepsza odpowiedź na to pytanie, a także na wiele innych podobnych pytań
Nikita 웃
Ta odpowiedź jest rzeczywiście pouczająca, ale uważam, że zadaniem programisty aplikacji nie jest debugowanie rdzenia serwera. Rzeczywiście, jest to o wiele łatwiejsze, jeśli masz pełny ślad stosu, ale co dalej? poprosić o naprawienie tego na żądanie ściągnięcia? Nie każdy jest devopsem lub jest w stanie zrozumieć język niskiego poziomu, taki jak C. Więc ostatecznie uważam, że byłoby znacznie łatwiej, gdyby programiści nie popełnili błędów zarządzania pamięcią. Co, jak sugerujesz, jest dość powszechne w przypadku opcache, ale nie jest zaskakujące, że nie we wszystkich modułach, ponieważ znasz niektórych programistów, którzy wiedzą, jak tworzyć.
job3dot5
46

Otrzymałem ten sam błąd w PHP 5.5 i zwiększenie buforowania wyjścia nie pomogło. Nie korzystałem też z APC, więc to nie był problem. W końcu wyśledziłem go do opcache , po prostu musiałem go wyłączyć z CLI. Było do tego określone ustawienie:

opcache.enable_cli=0

Po przełączeniu błąd zend_mm_heap uszkodzony zniknął.

Justin MacLeod
źródło
Ten sam problem i rozwiązanie tutaj! Dzięki!
Mauricio Sánchez,
2
Ogromny plus 1 za ten post. Próbowaliśmy wszystkiego, ale w końcu tylko to zadziałało.
Geoffrey Brier
7
Jestem pewien, że wiesz, że cli jest wersją php z linii poleceń i nie ma to nic wspólnego z modułem php używanym na przykład z serwerem WWW Apache i jestem ciekaw, jak pomogło wyłączenie opcache za pomocą cli? (Zakładam, że dzieje się to na serwerze WWW)
BIOHAZARD
@BioHazard, oprócz cli istnieje ogólne ustawienie opcache.enable = 0. Ale to nie pomaga w sprawie
Konstantin Iwanow
To powinna być akceptowana odpowiedź na to pytanie. Podniesienie parametru output_buffering nie jest rozwiązaniem, ponieważ może to mieć negatywne skutki uboczne dla Twojej witryny lub aplikacji, zgodnie z dokumentacją w php.ini.
BlueCola,
41

Jeśli korzystasz z Linuksa, spróbuj tego w wierszu poleceń

export USE_ZEND_ALLOC=0
Hittz
źródło
To mnie uratowało! Dodam to w pliku usługi php-fpm (przesłonięcie systemowe)
fzerorubigd
Zrobiło to dla mnie. Pamiętaj, aby dodać tę linię do, /etc/apache2/envvarsjeśli uruchamiasz to na serwerze ubuntu z apache i php zainstalowanym z ppas (apt). PHP 7.0-RC4 zaczął generować ten błąd, gdy instalowałem go z repozytorium ondrej.
Pedro Cordeiro
A także działa na oknach:set USE_ZEND_ALLOC=0
Nabi KAZ
22

Sprawdź unset()s. Upewnij się, że nie używasz unset()odniesień do $this(lub odpowiedników) w destruktorach i to unset()w destruktorach nie powoduje spadku liczby odwołań do tego samego obiektu do 0. Zrobiłem kilka badań i odkryłem, że to zwykle powoduje stertę korupcja.

Istnieje raport o błędzie PHP dotyczący błędu zend_mm_heap uszkodzony . Zobacz komentarz, [2011-08-31 07:49 UTC] f dot ardelian at gmail dot comaby zobaczyć przykład, jak go odtworzyć.

Mam wrażenie, że wszystkie inne „rozwiązania” (zmiana php.ini, kompilacja PHP ze źródła z mniejszą liczbą modułów itp.) Po prostu ukrywają problem.

f.ardelian
źródło
6
Otrzymałem ten problem z prostym html domem i zmieniłem go z nieskonfigurowanego na $ simplehtmldom-> clear (), co rozwiązało moje problemy, dzięki!
alexkb
9

Dla mnie żadna z poprzednich odpowiedzi nie działała, dopóki nie spróbowałem:

opcache.fast_shutdown=0

Jak dotąd to wydaje się działać.

Używam PHP 5.6 z PHP-FPM i Apache proxy_fcgi, jeśli to ma znaczenie ...

Jesús Carrera
źródło
1
Jest mnóstwo odpowiedzi „ja też” dla wszystkich różnych scenariuszy, ale wydawało się to najbardziej podobne do mojej konfiguracji i boom - ta dokładna zmiana wydaje się wyeliminować mój problem.
lkraav
6

W moim przypadku przyczyną tego błędu było to, że jedna z tablic stawała się bardzo duża. Ustawiłem mój skrypt tak, aby resetował tablicę przy każdej iteracji i to rozwiązało problem.

Piotr
źródło
Zrobiło to dla mnie - dzięki! Nie sądziłem, że śmieciarz uwolni pamięć cyklicznego odniesienia, więc nie sprawdziłem tego.
pół-szybki
5

Zgodnie z narzędziem do śledzenia błędów, ustaw opcache.fast_shutdown=0. Szybkie zamykanie używa menedżera pamięci Zend do porządkowania bałaganu, to wyłącza to.

Taco de Wolff
źródło
Naprawiono błąd „zend_mm_heap uszkodzony” w naszym CentOS Linux w wersji 7.2.1511, PHP 5.5.38. Możemy teraz wznowić korzystanie z pamięci podręcznej kodu operacji. Noc i dzień bez niego.
Richard Ginsberg
Dzięki za przypomnienie, to był dokładnie mój problem!
Weasler
4

Myślę, że nie ma tu jednej odpowiedzi, więc dodam moje doświadczenie. Widziałem ten sam błąd wraz z losowymi segfaultami httpd. To był serwer cPanel. Omawianym symptomem było to, że apache losowo resetował połączenie (brak danych otrzymanych w przeglądarce Chrome lub połączenie zostało zresetowane w przeglądarce Firefox). Były pozornie przypadkowe - przez większość czasu działało, czasami nie.

Kiedy dotarłem na scenę, buforowanie wyjścia było WYŁĄCZONE. Czytając ten wątek, który wskazywał na buforowanie wyjścia, włączyłem go (= 4096), aby zobaczyć, co się stanie. W tym momencie wszyscy zaczęli pokazywać błędy. To dobrze, że błąd był teraz powtarzalny.

Przeszedłem i zacząłem wyłączać rozszerzenia. Wśród nich eaccellerator, pdo, ioncube loader i wiele innych, które wyglądały na podejrzane, ale nic nie pomogło.

W końcu znalazłem niegrzeczne rozszerzenie PHP jako „homeloader.so”, które wydaje się być czymś w rodzaju modułu cPanel-easy-installer. Po usunięciu nie miałem żadnych innych problemów.

W tej notatce wygląda na to, że jest to ogólny komunikat o błędzie, więc Twój przebieg będzie się różnić w przypadku wszystkich tych odpowiedzi, najlepszy sposób działania, jaki możesz podjąć:

  • Powtarzaj błąd (jakie warunki?) Za każdym razem
  • Znajdź wspólny czynnik
  • Wybiórczo wyłączaj dowolne moduły PHP, opcje itp. (Lub, jeśli się spieszysz, wyłącz je wszystkie, aby zobaczyć, czy to pomaga, a następnie włączaj je ponownie, aż znowu się zepsują)
  • Jeśli to nie pomoże, wiele z tych odpowiedzi sugeruje, że kod może zostać opublikowany. Ponownie, kluczem jest powtórzenie błędu dla każdego żądania, aby można było go zawęzić. Jeśli podejrzewasz, że jakiś fragment kodu to robi, po raz kolejny, gdy błąd się powtórzy, po prostu usuwaj kod, aż błąd ustanie. Po zatrzymaniu wiesz, że przyczyną był ostatni usunięty fragment kodu.

W przypadku niepowodzenia wszystkich powyższych, możesz również spróbować następujących rzeczy:

  • Aktualizacja lub ponowna kompilacja PHP. Mam nadzieję, że naprawiono każdy błąd powodujący problem.
  • Przenieś swój kod do innego (testowego) środowiska. Jeśli to rozwiąże problem, co się zmieniło? opcje php.ini? Wersja PHP? itp...

Powodzenia.

AB Carroll
źródło
3

Zmagałem się z tym problemem przez tydzień, to zadziałało dla mnie, a przynajmniej tak się wydaje

W php.inidokonać tych zmian

report_memleaks = Off  
report_zend_debug = 0  

Moja konfiguracja to

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

To nie zadziałało.

Więc spróbowałem użyć skryptu testowego i spróbowałem nagrać, gdzie skrypt się rozłącza. Odkryłem, że tuż przed wystąpieniem błędu została utworzona instancja obiektu php i ukończenie tego, co obiekt miał zrobić, zajęło ponad 3 sekundy, podczas gdy w poprzednich pętlach trwało to maksymalnie 0,4 sekundy. Przeprowadziłem ten test kilka razy i za każdym razem tak samo. Pomyślałem, że zamiast tworzyć nowy obiekt za każdym razem (jest tu długa pętla), powinienem ponownie użyć obiektu. Do tej pory testowałem skrypt kilkanaście razy i zniknęły błędy pamięci!

sam
źródło
1
To działało przez chwilę, ale błąd powrócił. Jak to zatrzymać?
sam
To samo działało dla mnie na Mac Mavericks z MAMP PRO 2.1.1.
MutantMahesh
To rozwiązanie nie rozwiązało problemu na stałe i ponownie zaczynam otrzymywać ten błąd.
MutantMahesh
7
Z pewnością jest to po prostu wyłączenie zgłaszania błędów, a nie naprawienie problemu?
Robert Went
2

Poszukaj dowolnego modułu, który używa buforowania, i wyłącz go selektywnie.

Używam PHP 5.3.5 na CentOS 4.8 i po wykonaniu tej czynności stwierdziłem, że eaccelerator wymaga aktualizacji.

Scott Davey
źródło
2

Właśnie miałem ten problem na serwerze, który posiadam, a główną przyczyną był APC. Skomentowałem rozszerzenie „apc.so” w pliku php.ini, ponownie załadowałem Apache i strony od razu zaczęły działać.

Vance Lucas
źródło
2

Próbowałem wszystkiego powyżej i zend.enable_gc = 0- jedyne ustawienie konfiguracji, które mi pomogło.

PHP 5.3.10-1ubuntu3.2 z Suhosin-Patch (cli) (zbudowany: 13 czerwca 2012 17:19:58)

Bethrezen
źródło
2

Wystąpił ten błąd podczas korzystania ze sterownika Mongo 2.2 dla PHP:

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

^^ NIE DZIAŁA

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

^^ DZIAŁA! (?!)

hernanc
źródło
Ta odpowiedź pomogła mi debugować, przechodząc na ścieżkę problemów z Mongo. W moim przypadku, sterownik PHP 5.6 + Mongo 1.6.9, komunikat o uszkodzeniu zend_mm_heap został wyrzucony podczas iteracji i odpytywania wartości z tablicy zapełnionej wcześniej przezforeach(selectCollection()->find()) { $arr = .. }
Mihai MATEI
2

W PHP 5.3, po wielu poszukiwaniach, oto rozwiązanie, które zadziałało:

Mam wyłączone zbieranie śmieci PHP na tej stronie, dodając:

<? gc_disable(); ?>

do końca problematycznej strony, przez co wszystkie błędy zniknęły.

źródło .

Kuf
źródło
2

Myślę, że wiele powodów może powodować ten problem. W moim przypadku nazywam 2 klasy o tej samej nazwie, a jedna spróbuje załadować inną.

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

I to powoduje ten problem w moim przypadku.

(Używając laravel framework, uruchamiając php artisan db: seed w rzeczywistości)

Yarco
źródło
1

Miałem ten sam problem i kiedy miałem nieprawidłowy adres IP dla session.save_path dla sesji memcached. Zmiana adresu IP na poprawny rozwiązała problem.

Travis Derouin
źródło
1

Jeśli używasz cech, a cecha jest ładowana po klasie (np. W przypadku automatycznego ładowania), musisz wcześniej załadować cechę.

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

Uwaga: ten błąd jest bardzo losowy; ze względu na swoją naturę.

srcspider
źródło
1

U mnie problemem był pdo_mysql. Zapytanie zwróciło 1960 wyników. Próbowałem zwrócić 1900 płyt i działa. Problemem jest więc pdo_mysql i zbyt duża tablica. Przepisałem zapytanie z oryginalnym rozszerzeniem mysql i zadziałało.

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

Apache nie zgłosił żadnych poprzednich błędów.

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)
łącze szerokopasmowe
źródło
1

„Zend_mm_heap uszkodzony” oznacza problemy z zarządzaniem pamięcią. Może być spowodowane przez dowolny moduł PHP. W moim przypadku instalacja APC się powiodła. Teoretycznie mogą pomóc również inne pakiety, takie jak eAccelerator, XDebug itp. Lub, jeśli masz zainstalowane tego rodzaju moduły, spróbuj je wyłączyć.

Muto
źródło
1

Piszę rozszerzenie php i również napotykam ten problem. Kiedy wywołuję funkcję extern ze skomplikowanymi parametrami z mojego rozszerzenia, pojawia się ten błąd.

Powodem jest to, że nie przydzielam pamięci dla parametru (char *) w funkcji extern. Jeśli piszesz rozszerzenie tego samego rodzaju, zwróć na to uwagę.

cedricliang
źródło
0

Dla mnie to ZendDebugger spowodował wyciek pamięci i spowodował awarię MemoryManagera.

Wyłączyłem go i obecnie szukam nowszej wersji. Jeśli nie mogę znaleźć, przełączę się na xdebug ...

Structed
źródło
0

Ponieważ nigdy nie znalazłem rozwiązania tego problemu, zdecydowałem się zaktualizować moje środowisko LAMP. Poszedłem do Ubuntu 10.4 LTS z PHP 5.3.x. Wydaje się, że to zatrzymało problem.

bkulyk
źródło
0

W moim przypadku zapomniałem w kodzie:

);

Bawiłem się i zapomniałem o tym w kodzie tu i ówdzie - w niektórych miejscach dostałem uszkodzenie stosu, niektóre przypadki po prostu zwykły stary błąd:

[Wed Jun 08 17:23:21 2011] [uwaga] sygnał wyjścia dziecka pid 5720 Błąd segmentacji (11)

Jestem na Macu 10.6.7 i Xampp.

dsomnus
źródło
0

Zauważyłem również ten błąd i SIGSEGV podczas uruchamiania starego kodu, który używa znaku „&” do jawnego wymuszania odwołań podczas uruchamiania go w PHP 5.2+.

Phillip Whelan
źródło
0

Oprawa

assert.active = 0 

w php.ini pomogło mi (wyłączyło asercje typu w php5UTF8bibliotece i zend_mm_heap corruptedodeszło)

Wasilij
źródło
0

Dla mnie problem polegał na awarii demona memcached, ponieważ PHP zostało skonfigurowane do przechowywania informacji o sesji w memcached. Zjadał 100% procesora i dziwnie się zachowywał. Po ponownym uruchomieniu memcached zniknął problem.

Justinas Jaronis
źródło
0

Ponieważ żadna z pozostałych odpowiedzi nie rozwiązała tego problemu, miałem ten problem w php 5.4, gdy przypadkowo uruchomiłem nieskończoną pętlę.

Mikayla Maki
źródło
0

Kilka wskazówek, które mogą komuś pomóc

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

użycie var_dummp () w rzeczywistości nie jest błędem, zostało umieszczone tylko w celu debugowania i zostanie usunięte w kodzie produkcyjnym. Ale prawdziwe miejsce, w którym wydarzyło się zend_mm_heap, to drugie miejsce.

lexand
źródło
0

Byłem w tej samej sytuacji tutaj nic powyżej nie pomogło, a sprawdzając poważniej znajduję swój problem, polega na try do die (header ()) po wysłaniu jakiegoś wyjścia do bufora, człowiek który to zrobił w kodzie zapomniał o zasobach CakePHP i nie wykonał prostego polecenia „return $ this-> redirect ($ url)”.

Na tym polegał problem, próbując wymyślić na nowo studnię.

Mam nadzieję, że ten związek komuś pomoże!

Newton Pasqualini Filho
źródło