Apa yang dimaksud dengan "zend_mm_heap rusak"

126

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

bkulyk
sumber
2
Saya dulu USE_ZEND_ALLOC=0mendapatkan stacktrace di log kesalahan dan menemukan bug /usr/sbin/httpd: corrupted double-linked list, saya menemukan bahwa mengomentari opcache.fast_shutdown=1bekerja untuk saya.
Spidfire
Ya, sama di sini. Lihat juga laporan lain lebih lanjut di bawah stackoverflow.com/a/35212026/35946
lkraav
Saya memiliki hal yang sama menggunakan Laravel. Saya menyuntikkan kelas ke konstruktor kelas lain. Kelas saya menyuntikkan, menyuntikkan kelas itu disuntikkan, pada dasarnya menciptakan referensi melingkar yang menyebabkan masalah tumpukan.
Thomas
1
Mulai ulang server Apache untuk solusi tercepat dan sementara :)
Leopathu

Jawaban:

52

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

dsmithers
sumber
59
Tingkatkan ke apa? Mengapa perubahan ini membuat kesalahan ini hilang?
JDS
2
@ JDS jawaban ini membantu menjelaskan apa output_buffering dan mengapa meningkatkannya dapat membantu stackoverflow.com/a/2832179/704803
andrewtweber
8
@andrewtweber Saya tahu apa itu ob, saya bertanya-tanya tentang detail spesifik yang ditinggalkan dari jawaban dsmithers, karena saya memiliki pesan kesalahan yang sama dengan op. Sebagai penutup: ternyata masalah saya adalah pengaturan yang salah konfigurasi untuk memcached. Terimakasih Meskipun!
JDS
@ JDS pengaturan kesalahan konfigurasi apa?
Kyle Cronin
3
@KyleCronin platform layanan kami menggunakan Memcache dalam produksi. Namun, beberapa contoh - non-produksi / kotak pasir, pelanggan sekali pakai - tidak menggunakan memcache. Dalam kasus terakhir, saya memiliki konfigurasi yang disalin dari produksi ke pelanggan satu kali, dan konfigurasi memcache menunjukkan URI server memcache yang tidak tersedia di lingkungan itu. Saya menghapus baris dan menonaktifkan memcache di aplikasi, dan masalahnya hilang. Jadi, cerita panjang, masalah yang sangat spesifik yang dihadapi dalam lingkungan tertentu, yang mungkin tidak berlaku secara umum. Tapi, karena Anda bertanya ...
JDS
47

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.

Joe Watkins
sumber
Jadi masalah yang mendasarinya adalah versi PHP mana yang Anda jalankan?
Ismael
@Ishmael Ya, juga versi semua ekstensi, karena peringatan mungkin muncul dari ekstensi.
Uskup
2
Jawaban ini sepertinya yang terbaik untuk saya. Saya pribadi mengalami masalah beberapa kali dan itu selalu terkait dengan ekstensi yang salah (dalam kasus saya, perpustakaan ejaan Enchant). Selain dari php itu sendiri, itu juga bisa menjadi lingkungan yang buruk (ketidakcocokan versi lib, dependensi yang salah, dll.)
Fractalizer
1
Sejauh ini, jawaban terbaik untuk pertanyaan ini, dan untuk banyak pertanyaan serupa lainnya
Nikita 웃
Jawaban ini memang instruktif tetapi saya percaya itu bukan tugas pengembang aplikasi untuk men-debug inti server. Memang jauh lebih mudah jika Anda memiliki jejak tumpukan penuh tetapi apa selanjutnya? meminta untuk memperbaikinya pada permintaan tarik? Tidak semua orang adalah devops atau mampu memahami bahasa tingkat rendah seperti C. Sebaliknya juga benar. Jadi pada akhirnya saya percaya itu akan jauh lebih mudah adalah para pengembang tidak akan membuat kesalahan manajemen memori sejak awal. Yang seperti yang Anda sarankan agak umum dengan opcache, tetapi tidak mengherankan tidak dengan semua modul, karena Anda tahu beberapa dev tahu bagaimana untuk dev.
job3dot5
46

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.

Justin MacLeod
sumber
Masalah dan solusinya sama di sini! Terima kasih!
Mauricio Sánchez
2
Besar plus 1 untuk pos ini. Kami mencoba segalanya tetapi pada akhirnya, hanya ini yang berhasil.
Geoffrey Brier
7
Saya yakin Anda tahu bahwa cli adalah versi baris perintah dari php dan itu tidak ada hubungannya dengan modul php yang digunakan dengan server web apache misalnya dan saya ingin tahu bagaimana menonaktifkan opcache dengan cli membantu? (Saya berasumsi bahwa ini terjadi pada server web)
BIOHAZARD
@BioHazard, terlepas dari cli ada pengaturan umum opcache.enable = 0. Tapi itu tidak perlu membantu kasus ini
Konstantin Ivanov
Ini harus menjadi jawaban yang diterima untuk pertanyaan ini. Meningkatkan output_buffering bukanlah jawabannya, karena ini dapat memiliki efek samping negatif ke situs web atau aplikasi Anda, menurut dokumentasi di php.ini.
BlueCola
41

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

export USE_ZEND_ALLOC=0
Hittz
sumber
Ini menyelamatkan saya! Saya menambahkan ini di dalam file layanan php-fpm (systemd override)
fzerorubigd
Ini berhasil untuk saya. Ingatlah untuk menambahkan baris ini ke /etc/apache2/envvarsjika Anda menjalankan ini di server ubuntu dengan apache dan php diinstal dari ppas (apt). PHP 7.0-RC4 mulai melempar kesalahan ini ketika saya menginstalnya dari repositori ondrej.
Pedro Cordeiro
Dan itu juga berfungsi di windows:set USE_ZEND_ALLOC=0
Nabi KAZ
22

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.

fardardian
sumber
6
Saya mendapatkan masalah ini dengan dom html sederhana, dan berubah dari tidak disetel menjadi $ simplehtmldom-> clear () yang menyelesaikan masalah saya, terima kasih!
alexkb
9

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

Jesús Carrera
sumber
1
Ada banyak tanggapan "saya juga" untuk semua skenario yang berbeda, tetapi ini tampaknya paling mirip dengan konfigurasi saya, dan boom - perubahan yang tepat ini tampaknya telah menghilangkan masalah saya.
lkraav
6

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.

Piotr
sumber
Ini berhasil untuk saya - terima kasih! Saya tidak berpikir pengumpul sampah akan membebaskan memori dari referensi siklik, jadi saya tidak memeriksanya.
setengah cepat
5

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

Taco de Wolff
sumber
Ini memperbaiki "zend_mm_heap rusak" pada rilis CentOS Linux kami 7.2.1511, PHP 5.5.38. Kami sekarang dapat melanjutkan menggunakan cache opcode. Siang dan malam tanpa itu.
Richard Ginsberg
Terima kasih atas pengingatnya, ini persis masalah saya!
Weasler
4

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.

AB Carroll
sumber
3

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!

sam
sumber
1
Ini berfungsi untuk sementara waktu, tetapi kesalahan sudah kembali. Bagaimana saya menghentikan ini?
sam
Hal yang sama berlaku untuk saya di mac mavericks dengan MAMP PRO 2.1.1.
MutantMahesh
Solusi ini tidak memperbaiki masalah secara permanen, saya mulai mendapatkan kesalahan ini lagi.
MutantMahesh
7
Tentunya ini hanya mematikan pelaporan kesalahan daripada memperbaiki masalah?
Robert Went
2

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.

Scott Davey
sumber
2

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.

Vance Lucas
sumber
2

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)

Bethrezen
sumber
2

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

hernanc
sumber
Jawaban ini membantu saya men-debug, melanjutkan jalur masalah Mongo. Dalam kasus saya, driver PHP 5.6 + Mongo 1.6.9, pesan rusak zend_mm_heap dilemparkan ketika mengulang dan meminta nilai dari array yang sebelumnya diisi melaluiforeach(selectCollection()->find()) { $arr = .. }
Mihai MATEI
2

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 .

Kuf
sumber
2

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)

Yarco
sumber
1

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.

Travis Derouin
sumber
1

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.

srcspider
sumber
1

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

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

Muto
sumber
1

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.

cedricliang
sumber
0

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

Tersusun
sumber
0

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.

bkulyk
sumber
0

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.

dsomnus
sumber
0

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

Phillip Whelan
sumber
0

Pengaturan

assert.active = 0 

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

Vasiliy
sumber
0

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.

Justinas Jaronis
sumber
0

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

Mikayla Maki
sumber
0

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.

lexand
sumber
0

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!

Newton Pasqualini Filho
sumber