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

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

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.

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

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

export USE_ZEND_ALLOC=0

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.

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

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.

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.

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.

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!

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.

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

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)

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

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 .

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)

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.

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

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)

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

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

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

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.

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.

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

Oprawa

assert.active = 0 

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

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.

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

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.

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!