Tiba-tiba saya mengalami masalah dengan aplikasi saya yang belum pernah saya miliki sebelumnya. Saya memutuskan untuk memeriksa log kesalahan Apache, dan saya menemukan pesan kesalahan yang mengatakan "zend_mm_heap rusak". Apa artinya ini.

OS: Fedora Core 8 Apache: 2.2.9 PHP: 5.2.6

Setelah banyak percobaan dan kesalahan, saya menemukan bahwa jika saya meningkatkan output_bufferingnilai dalam file php.ini, kesalahan ini hilang

Ini bukan masalah yang perlu dipecahkan dengan mengubah opsi konfigurasi.

Mengubah opsi konfigurasi kadang-kadang akan berdampak positif, tetapi bisa dengan mudah memperburuk keadaan, atau tidak melakukan apa-apa sama sekali.

Sifat kesalahannya adalah ini:

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

Kode di atas dapat dikompilasi dengan:

gcc -g -o corrupt corrupt.c

Menjalankan kode dengan valgrind Anda dapat melihat banyak kesalahan memori, yang berujung pada kesalahan segmentasi:

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

Jika Anda tidak tahu, Anda sudah tahu bahwa itu memadalah tumpukan memori yang dialokasikan; Tumpukan mengacu pada wilayah memori yang tersedia untuk program saat runtime, karena program secara eksplisit memintanya (dengan malloc dalam kasus kami).

Jika Anda bermain-main dengan kode mengerikan, Anda akan menemukan bahwa tidak semua pernyataan yang jelas salah menghasilkan kesalahan segmentasi (kesalahan penghentian fatal).

Saya secara eksplisit membuat kesalahan dalam kode contoh, tetapi jenis kesalahan yang sama terjadi dengan sangat mudah dalam lingkungan yang dikelola memori: Jika beberapa kode tidak mempertahankan refcount variabel (atau simbol lain) dengan cara yang benar, misalnya jika gratis itu terlalu dini, sepotong kode lain mungkin membaca dari memori yang sudah bebas, jika entah bagaimana menyimpan alamat yang salah, sepotong kode lain mungkin menulis ke memori yang tidak valid, mungkin bebas dua kali ...

Ini bukan masalah yang bisa didebug dalam PHP, mereka benar-benar membutuhkan perhatian pengembang internal.

Tindakan yang harus dilakukan adalah:

1. Buka laporan bug di http://bugs.php.net
   • Jika Anda memiliki segfault, cobalah untuk menyediakan backtrace
   • Sertakan sebanyak mungkin informasi konfigurasi yang sesuai, khususnya, jika Anda menggunakan opcache termasuk level optimisasi.
   • Terus periksa laporan bug untuk pembaruan, informasi lebih lanjut mungkin diminta.
2. Jika opcache Anda dimuat, nonaktifkan optimisasi
   • Saya tidak memilih opcache, itu bagus, tetapi beberapa optimasi itu diketahui menyebabkan kesalahan.
   • Jika itu tidak berhasil, walaupun kode Anda mungkin lebih lambat, coba bongkar dulu opcache.
   • Jika salah satu dari ini mengubah atau memperbaiki masalah, perbarui laporan bug yang Anda buat.
3. Nonaktifkan semua ekstensi yang tidak perlu sekaligus.
   • Mulailah untuk mengaktifkan semua ekstensi Anda secara individual, dengan saksama menguji setelah setiap perubahan konfigurasi.
   • Jika Anda menemukan ekstensi masalah, perbarui laporan bug Anda dengan info lebih lanjut.
4. Keuntungan.

Mungkin tidak ada untung ... Saya katakan di awal, Anda mungkin dapat menemukan cara untuk mengubah gejala Anda dengan mengacaukan konfigurasi, tetapi ini sangat memukul dan meleset, dan tidak membantu saat berikutnya Anda memiliki zend_mm_heap corruptedpesan yang sama , hanya ada begitu banyak opsi konfigurasi.

Sangat penting bagi kami untuk membuat laporan bug ketika kami menemukan bug, kami tidak dapat berasumsi bahwa orang berikutnya yang memukul bug akan melakukannya ... lebih mungkin daripada tidak, resolusi sebenarnya sama sekali tidak misterius, jika Anda membuat orang yang tepat menyadari masalah tersebut.

USE_ZEND_ALLOC

Jika Anda mengatur USE_ZEND_ALLOC=0di lingkungan, ini menonaktifkan manajer memori Zend sendiri; Manajer memori Zend memastikan bahwa setiap permintaan memiliki tumpukan itu sendiri, bahwa semua memori dikosongkan pada akhir permintaan, dan dioptimalkan untuk alokasi potongan memori dengan ukuran yang tepat untuk PHP.

Menonaktifkan itu akan menonaktifkan optimasi tersebut, yang lebih penting itu kemungkinan akan membuat kebocoran memori, karena ada banyak kode ekstensi yang bergantung pada Zend MM untuk membebaskan memori bagi mereka di akhir permintaan (tut, tut).

Mungkin juga menyembunyikan gejalanya, tetapi tumpukan sistem dapat rusak dengan cara yang persis sama dengan tumpukan Zend.

Mungkin tampaknya lebih toleran atau kurang toleran, tetapi memperbaiki akar penyebab masalah, itu tidak bisa .

Kemampuan untuk menonaktifkannya sama sekali, adalah untuk kepentingan pengembang internal; Anda tidak boleh menggunakan PHP dengan Zend MM dinonaktifkan.

Saya mendapatkan kesalahan yang sama di bawah PHP 5.5 dan meningkatkan buffering output tidak membantu. Saya juga tidak menjalankan APC jadi bukan itu masalahnya. Saya akhirnya melacaknya ke opcache , saya hanya perlu menonaktifkannya dari cli. Ada pengaturan khusus untuk ini:

opcache.enable_cli=0

Setelah beralih, kesalahan rusak zend_mm_heap hilang.

Jika Anda berada di kotak Linux, coba ini di baris perintah

export USE_ZEND_ALLOC=0

Periksa unset()s. Pastikan Anda tidak unset()referensi ke $this(atau yang setara) di destruktor dan yang ada unset()di destruktor tidak menyebabkan referensi referensi ke objek yang sama turun menjadi 0. Saya sudah melakukan penelitian dan menemukan bahwa itulah yang biasanya menyebabkan tumpukan korupsi.

Ada laporan bug PHP tentang kesalahan rusak zend_mm_heap . Lihat komentar [2011-08-31 07:49 UTC] f dot ardelian at gmail dot comuntuk contoh bagaimana mereproduksinya.

Saya merasa bahwa semua "solusi" lainnya (ubah php.ini, kompilasi PHP dari sumber dengan modul yang lebih sedikit, dll.) Hanya menyembunyikan masalahnya.

Bagi saya tidak ada jawaban sebelumnya yang berfungsi, sampai saya mencoba:

opcache.fast_shutdown=0

Itu sepertinya berhasil sejauh ini.

Saya menggunakan PHP 5.6 dengan PHP-FPM dan Apache proxy_fcgi, jika itu penting ...

Dalam kasus saya, penyebab kesalahan ini adalah salah satu array menjadi sangat besar. Saya telah mengatur skrip saya untuk mengatur ulang array pada setiap iterasi dan itu mengurutkan masalah.

Sesuai pelacak bug, atur opcache.fast_shutdown=0. Shutdown cepat menggunakan manajer memori Zend untuk membersihkan kekacauannya, ini menonaktifkannya.

Saya tidak berpikir ada satu jawaban di sini, jadi saya akan menambahkan pengalaman saya. Saya melihat kesalahan yang sama ini bersama dengan segfault httpd acak. Ini adalah server cPanel. Gejala yang dimaksud adalah apache secara acak akan mengatur ulang koneksi (Tidak ada data yang diterima dalam chrome, atau koneksi diatur ulang di firefox). Ini tampaknya acak - sebagian besar waktu itu berhasil, kadang-kadang tidak.

Ketika saya tiba di tempat output, buffering OFF. Dengan membaca utas ini, yang mengisyaratkan buffering keluaran, saya menyalakannya (= 4096) untuk melihat apa yang akan terjadi. Pada titik ini, mereka semua mulai menunjukkan kesalahan. Ini bagus bahwa kesalahan sekarang dapat diulang.

Saya melakukan dan mulai menonaktifkan ekstensi. Diantaranya, eaccellerator, pdo, loader ioncube, dan banyak yang tampak mencurigakan, tetapi tidak ada yang membantu.

Saya akhirnya menemukan ekstensi PHP nakal sebagai "homeloader.so", yang tampaknya semacam modul cPanel-easy-installer. Setelah dihapus, saya belum mengalami masalah lain.

Pada catatan itu, tampaknya ini adalah pesan kesalahan umum sehingga jarak tempuh Anda akan bervariasi dengan semua jawaban ini, tindakan terbaik yang dapat Anda ambil:

• Buat kesalahan berulang (kondisi apa?) Setiap kali
• Temukan faktor umum
• Nonaktifkan modul PHP, opsi, dll. (Atau, jika Anda terburu-buru, nonaktifkan semuanya untuk melihat apakah itu membantu, lalu aktifkan kembali secara selektif hingga rusak lagi)
• Jika ini gagal membantu, banyak dari jawaban ini mengisyaratkan bahwa itu bisa berupa kode yang dirilis. Sekali lagi, kuncinya adalah membuat kesalahan berulang setiap permintaan sehingga Anda dapat mempersempitnya. Jika Anda menduga sepotong kode melakukan ini, sekali lagi, setelah kesalahan berulang, cukup hapus kode sampai kesalahan berhenti. Setelah berhenti, Anda tahu bahwa bagian terakhir dari kode yang Anda hapus adalah pelakunya.

Gagal semua hal di atas, Anda juga dapat mencoba hal-hal seperti:

• Memutakhirkan atau mengkompilasi ulang PHP. Semoga bug apa pun yang menyebabkan masalah Anda diperbaiki.
• Pindahkan kode Anda ke lingkungan (pengujian) yang berbeda. Jika ini memperbaiki masalah, apa yang berubah? opsi php.ini? Versi PHP? dll ...

Semoga berhasil.

Saya bergulat dengan masalah ini, selama seminggu, Ini bekerja untuk saya, atau setidaknya begitulah tampaknya

Dalam php.inimelakukan perubahan ini

report_memleaks = Off  
report_zend_debug = 0  

Pengaturan saya adalah

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

Ini tidak berhasil.

Jadi saya mencoba menggunakan skrip patokan, dan mencoba merekam di mana skrip digantung. Saya menemukan bahwa tepat sebelum kesalahan, objek php dibuat, dan butuh lebih dari 3 detik untuk menyelesaikan apa yang seharusnya dilakukan objek, sedangkan pada loop sebelumnya butuh maks 0,4 detik. Saya menjalankan tes ini beberapa kali, dan setiap kali sama. Saya berpikir alih-alih membuat objek baru setiap kali, (ada loop panjang di sini), saya harus menggunakan kembali objek tersebut. Saya telah menguji skrip lebih dari selusin kali sejauh ini, dan kesalahan memori telah hilang!

Cari modul apa saja yang menggunakan buffering, dan nonaktifkan secara selektif.

Saya menjalankan PHP 5.3.5 pada CentOS 4.8, dan setelah melakukan ini saya menemukan eaccelerator perlu ditingkatkan.

Saya baru saja mengalami masalah ini juga di server yang saya miliki, dan akar masalahnya adalah APC. Saya berkomentar ekstensi "apc.so" di file php.ini, memuat ulang Apache, dan situs kembali muncul.

Saya sudah mencoba semuanya di atas dan zend.enable_gc = 0- satu-satunya pengaturan konfigurasi, yang membantu saya.

PHP 5.3.10-1ubuntu3.2 dengan Suhosin-Patch (cli) (dibangun: 13 Juni 2012 17:19:58)

Saya mengalami kesalahan ini menggunakan driver Mongo 2.2 untuk PHP:

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

^^ TIDAK BEKERJA

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

^^ BEKERJA! (?!)

Di PHP 5.3, setelah banyak pencarian, ini adalah solusi yang bekerja untuk saya:

Saya telah menonaktifkan pengumpulan sampah PHP untuk halaman ini dengan menambahkan:

<? gc_disable(); ?>

ke akhir halaman bermasalah, yang membuat semua kesalahan hilang.

sumber .

Saya pikir banyak alasan dapat menyebabkan masalah ini. Dan dalam kasus saya, saya memberi nama 2 kelas dengan nama yang sama, dan satu akan mencoba memuat yang lain.

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

Dan itu menyebabkan masalah ini dalam kasus saya.

(Menggunakan kerangka laravel, menjalankan php artisan db: seed in real)

Saya memiliki masalah yang sama dan ketika saya memiliki IP yang salah untuk session.save_path untuk sesi memcached. Mengubahnya ke IP yang benar memperbaiki masalah.

Jika Anda menggunakan sifat dan sifat tersebut dimuat setelah kelas (mis. Kasus autoloading), Anda perlu memuat sifat tersebut terlebih dahulu.

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

Catatan: bug ini sangat sangat acak; karena sifatnya itu.

Bagi saya masalahnya adalah menggunakan pdo_mysql. Permintaan mengembalikan hasil tahun 1960. Saya mencoba mengembalikan 1900 catatan dan berhasil. Jadi masalahnya adalah pdo_mysql dan array yang terlalu besar. Saya menulis ulang kueri dengan ekstensi mysql asli dan berhasil.

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

Apache tidak melaporkan kesalahan sebelumnya.

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 rusak" berarti masalah dengan manajemen memori. Dapat disebabkan oleh modul PHP apa pun. Dalam kasus saya menginstal APC berhasil. Secara teori, paket lain seperti eAccelerator, XDebug dll. Dapat membantu juga. Atau, jika Anda memiliki modul semacam itu yang diinstal, cobalah mematikannya.

Saya menulis ekstensi php dan juga menemui masalah ini. Ketika saya memanggil fungsi eksternal dengan parameter rumit dari ekstensi saya, kesalahan ini muncul.

Alasannya adalah saya tidak mengalokasikan memori untuk parameter (char *) dalam fungsi extern. Jika Anda menulis ekstensi yang sama, harap perhatikan ini.

Bagi saya, itu adalah ZendDebugger yang menyebabkan kebocoran memori dan membuat MemoryManager lumpuh.

Saya menonaktifkannya dan saat ini saya sedang mencari versi yang lebih baru. Jika saya tidak dapat menemukannya, saya akan beralih ke xdebug ...

Karena saya tidak pernah menemukan solusi untuk ini, saya memutuskan untuk memutakhirkan lingkungan LAMP saya. Saya pergi ke Ubuntu 10.4 LTS dengan PHP 5.3.x. Ini sepertinya telah menghentikan masalah bagi saya.

Dalam kasus saya, saya lupa mengikuti kode:

);

Saya bermain-main dan melupakannya dalam kode di sana-sini - di beberapa tempat saya mendapatkan banyak korupsi, beberapa kasus hanya karena kesalahan:

[Rab Jun 08 17:23:21 2011] [pemberitahuan] child pid 5720 signal exit Kesalahan segmentasi (11)

Saya di mac 10.6.7 dan xampp.

Saya juga melihat kesalahan ini dan SIGSEGV ketika menjalankan kode lama yang menggunakan '&' untuk secara paksa memaksa referensi saat menjalankannya di PHP 5.2+.

Pengaturan

assert.active = 0 

di php.ini membantu saya (ini mematikan pernyataan jenis di php5UTF8perpustakaan dan zend_mm_heap corruptedpergi)

Bagi saya masalahnya crash daemon memcached, karena PHP dikonfigurasi untuk menyimpan informasi sesi dalam memcached. Itu makan 100% cpu dan bertingkah aneh. Setelah memcached restart, masalah telah hilang.

Karena tidak ada jawaban lain yang menanganinya, saya mengalami masalah ini di php 5.4 ketika saya secara tidak sengaja menjalankan infinite loop.

Beberapa tips yang mungkin bisa membantu seseorang

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

menggunakan var_dummp () sebenarnya bukan kesalahan, itu ditempatkan hanya untuk debugging dan akan dihapus pada kode produksi. Tapi tempat nyata di mana zend_mm_heap terjadi adalah tempat kedua.

Saya dalam situasi yang sama di sini, tidak ada yang membantu di atas, dan memeriksa lebih serius saya menemukan masalah saya, itu terdiri dari coba lakukan mati (header ()) setelah mengirim beberapa output ke buffer, orang yang melakukan ini dalam Kode lupa tentang sumber daya CakePHP dan tidak membuat simples "kembalikan $ this-> redirect ($ url)".

Mencoba menemukan kembali sumur, inilah masalahnya.

Saya harap ini berhubungan membantu seseorang!