Birdenbire uygulamamla daha önce hiç yaşamadığım sorunlar yaşadım. Apache'nin hata günlüğünü kontrol etmeye karar verdim ve "zend_mm_heap bozuk" şeklinde bir hata mesajı buldum. Ne anlama geliyor.

İşletim Sistemi: Fedora Core 8 Apache: 2.2.9 PHP: 5.2.6

Çok fazla deneme output_bufferingyanılmadan sonra, php.ini dosyasındaki değeri arttırırsam bu hatanın kaybolduğunu gördüm.

Bu, yapılandırma seçeneklerini değiştirerek mutlaka çözülebilecek bir sorun değildir.

Yapılandırma seçeneklerini değiştirmek bazen olumlu bir etkiye sahip olabilir, ancak aynı şekilde işleri daha da kötüleştirebilir veya hiçbir şey yapmayabilir.

Hatanın doğası şudur:

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

Yukarıdaki kod şu şekilde derlenebilir:

gcc -g -o corrupt corrupt.c

Kodun valgrind ile yürütülmesi, bir bölümleme hatasıyla sonuçlanan birçok bellek hatasını görebilirsiniz:

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

Eğer bilmiyorsanız, membunun yığın ayrılmış bellek olduğunu zaten anlamışsınızdır ; Yığın, program açık bir şekilde istediğinden (bizim durumumuzda malloc ile) programın çalışma zamanında kullanabileceği bellek bölgesini ifade eder.

Eğer korkunç kodla oynarsanız, açıkça yanlış olan ifadelerin hepsinin bir bölümleme hatasıyla (ölümcül bir sonlandırma hatası) sonuçlanmadığını göreceksiniz.

Örnek kodda bu hataları açıkça yaptım, ancak bellek yönetimli bir ortamda aynı tür hatalar çok kolay oluyor: Örneğin bazı kodlar bir değişkenin (veya başka bir sembolün) refcount'unu doğru şekilde tutmuyorsa, çok erken serbest kalırsa, başka bir kod parçası zaten boş olan bellekten okuyabilir, adresi bir şekilde yanlış saklarsa, başka bir kod parçası geçersiz belleğe yazabilir, iki kez serbest bırakılabilir ...

Bunlar PHP'de hata ayıklanabilecek sorunlar değildir, kesinlikle bir dahili geliştiricinin dikkatini gerektirir.

Eylem süreci şöyle olmalıdır:

1. Http://bugs.php.net adresinde bir hata raporu açın
   • Segfault'unuz varsa, geri izleme sağlamaya çalışın
   • Özellikle opcache kullanıyorsanız, uygun göründüğü kadar çok yapılandırma bilgisi ekleyin optimizasyon düzeyi.
   • Güncellemeler için hata raporunu kontrol etmeye devam edin, daha fazla bilgi istenebilir.
2. Opcache yüklediyseniz optimizasyonları devre dışı bırakın
   • Opcache seçmiyorum, bu harika, ancak bazı optimizasyonlarının hatalara neden olduğu biliniyor.
   • Bu işe yaramazsa, kodunuz daha yavaş olsa bile, önce opcache'yi kaldırmayı deneyin.
   • Bunlardan herhangi biri sorunu değiştirir veya düzeltirse, yaptığınız hata raporunu güncelleyin.
3. Tüm gereksiz uzantıları aynı anda devre dışı bırakın .
   • Her yapılandırma değişikliğinden sonra kapsamlı bir test yaparak tüm uzantılarınızı ayrı ayrı etkinleştirmeye başlayın.
   • Sorun uzantısını bulursanız, hata raporunuzu daha fazla bilgi ile güncelleyin.
4. Kar.

Herhangi bir kar olmayabilir ... Başlangıçta, konfigürasyonla uğraşarak semptomlarınızı değiştirmenin bir yolunu bulabileceğinizi söyledim, ancak bu son derece isabetli ve bir dahaki sefere yardımcı olmuyor. aynı zend_mm_heap corruptedmesaj, yalnızca çok fazla yapılandırma seçeneği vardır.

Hatalar bulduğumuzda hata raporları oluşturmamız gerçekten önemlidir, hatayı bulan bir sonraki kişinin bunu yapacağını varsayamayız ... büyük olasılıkla, gerçek çözüm hiçbir şekilde gizemli değildir, eğer doğru insanlar sorunun farkında.

USE_ZEND_ALLOC

Ortama ayarlarsanız USE_ZEND_ALLOC=0, bu Zend'in kendi hafıza yöneticisini devre dışı bırakır; Zend'in bellek yöneticisi, her isteğin kendi yığınına sahip olmasını, bir isteğin sonunda tüm belleğin serbest bırakılmasını ve PHP için doğru boyutta bellek parçalarının tahsisi için optimize edilmesini sağlar.

Devre dışı bırakmak, bu optimizasyonları devre dışı bırakacaktır, daha da önemlisi, bir isteğin sonunda onlar için belleği boşaltmak için Zend MM'ye dayanan birçok uzantı kodu olduğundan büyük olasılıkla bellek sızıntıları yaratacaktır (tut, tut).

Semptomları da gizleyebilir , ancak sistem yığını, Zend'in yığınıyla tamamen aynı şekilde bozulabilir.

Daha hoşgörülü veya daha az hoşgörülü görünebilir, ancak sorunun temel nedenini çözemez, olamaz .

Tamamen devre dışı bırakma yeteneği, dahili geliştiricilerin yararınadır; Sen gerektiğini asla devre dışı Zend MM'li PHP dağıtın.

Aynı hatayı PHP 5.5 altında alıyordum ve çıktı arabelleğini artırmak yardımcı olmadı. Ben de APC çalıştırmıyordum, bu yüzden sorun bu değildi. Sonunda opcache'ye kadar izledim , sadece onu cli'dan devre dışı bırakmak zorunda kaldım. Bunun için belirli bir ayar vardı:

opcache.enable_cli=0

Bir kez değiştirildikten sonra zend_mm_heap bozuk hatası ortadan kalktı.

Linux kutusundaysanız, bunu komut satırında deneyin

export USE_ZEND_ALLOC=0

unset()S için kontrol edin . Emin değil mi Make unset()başvurular $thisyıkıcılar içinde (veya eşdeğeri) ve unset()biraz araştırma yapmış ve buldum aynı nesneye başvuru sayısı 0'a düşmesi yok neden yıkıcılar içinde s en genellikle yığın neyin sebep olduğunu yozlaşma.

Zend_mm_heap bozuk hatasıyla ilgili bir PHP hata raporu var . [2011-08-31 07:49 UTC] f dot ardelian at gmail dot comNasıl yeniden üretileceğine ilişkin bir örnek için yoruma bakın .

Tüm diğer "çözümlerin" (değiştirin php.ini, PHP'yi kaynaktan daha az modülle derleyin, vb.) Sorunu gizlediğini hissediyorum .

Benim için önceki cevapların hiçbiri işe yaramadı, deneyene kadar:

opcache.fast_shutdown=0

Şimdiye kadar işe yarıyor gibi görünüyor.

PHP 5.6'yı PHP-FPM ve Apache proxy_fcgi ile kullanıyorum, eğer önemliyse ...

Benim durumumda, bu hatanın nedeni dizilerden biri çok büyük hale geliyordu. Komut dizimi her yinelemede diziyi sıfırlayacak şekilde ayarladım ve bu sorunu sıraladı.

Hata izleyiciye göre ayarlayın opcache.fast_shutdown=0. Hızlı kapatma, dağınıklığını temizlemek için Zend bellek yöneticisini kullanır, bu onu devre dışı bırakır.

Burada tek bir cevap olduğunu sanmıyorum, bu yüzden deneyimlerimi ekleyeceğim. Aynı hatayı rastgele httpd segfaults ile birlikte gördüm. Bu bir cPanel sunucusuydu. Söz konusu belirti, apache'nin bağlantıyı rastgele olarak sıfırlamasıydı (Chrome'da veri alınmadı veya bağlantı firefox'ta sıfırlandı). Bunlar görünüşte rastgele - çoğu zaman işe yaradı, bazen işe yaramadı.

Sahneye vardığımda çıktı tamponlama KAPALI idi. Çıktı tamponlamasına işaret eden bu iş parçacığını okuyarak, ne olacağını görmek için açtım (= 4096). Bu noktada onlar hepsi hataları göstermeye başladı. Hatanın artık tekrarlanabilir olması güzeldi.

İnceledim ve uzantıları devre dışı bırakmaya başladım. Bunların arasında eaccellerator, pdo, ioncube loader ve şüpheli görünen , ancak hiçbiri yardımcı .

Sonunda yaramaz PHP uzantısını "homeloader.so" olarak buldum, bu bir tür cPanel-easy-installer modülü gibi görünüyor. Çıkardıktan sonra başka herhangi bir sorun yaşamadım.

Bu notta, bunun genel bir hata mesajı olduğu anlaşılıyor, bu nedenle milajınız tüm bu yanıtlarla değişecektir, yapabileceğiniz en iyi eylem şekli:

• Hatayı her seferinde tekrarlanabilir hale getirin (hangi koşullar?)
• Ortak faktörü bulun
• Tüm PHP modüllerini, seçeneklerini vb. Seçerek devre dışı bırakın (veya aceleniz varsa, yardımcı olup olmadığını görmek için hepsini devre dışı bırakın, ardından tekrar bozulana kadar seçerek yeniden etkinleştirin)
• Bu işe yaramazsa, bu yanıtların çoğu kodun serbest bırakılabileceğini ima eder. Yine, önemli olan hatayı her istekte tekrarlanabilir hale getirmektir, böylece onu daraltabilirsiniz. Bir kod parçasının bunu yaptığından şüpheleniyorsanız, hata tekrarlanabilir hale geldikten sonra, hata durana kadar kodu kaldırın. Durduğunda, kaldırdığınız son kod parçasının suçlu olduğunu bilirsiniz.

Yukarıdakilerin hiçbiri başarısız olursa, aşağıdaki gibi şeyleri de deneyebilirsiniz:

• PHP'yi yükseltme veya yeniden derleme. Umarım sorununuza neden olan hata giderilmiştir.
• Kodunuzu farklı bir (test) ortamına taşıyın. Bu sorunu çözerse ne değişti? php.ini seçenekleri? PHP sürümü? vb...

İyi şanslar.

Bu sorunla bir hafta boyunca boğuştum, Bu benim için çalıştı ya da en azından öyle görünüyor

Gelen php.inibu değişiklikleri yapmak

report_memleaks = Off  
report_zend_debug = 0  

Benim kurulumum

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

Bu işe yaramadı.

Bu yüzden bir kıyaslama senaryosu kullanmayı ve senaryonun takıldığı yeri kaydetmeyi denedim. Hatadan hemen önce, bir php nesnesinin somutlaştırıldığını ve nesnenin yapması gerekeni tamamlamasının 3 saniyeden fazla sürdüğünü, önceki döngülerde ise en fazla 0,4 saniye sürdüğünü keşfettim. Bu testi birkaç kez yaptım ve her seferinde aynı. Her seferinde yeni bir nesne yapmak yerine (burada uzun bir döngü var), nesneyi yeniden kullanmam gerektiğini düşündüm. Şimdiye kadar betiği bir düzineden fazla test ettim ve hafıza hataları ortadan kalktı!

Arabelleğe almayı kullanan herhangi bir modülü arayın ve seçici olarak devre dışı bırakın.

CentOS 4.8 üzerinde PHP 5.3.5 çalıştırıyorum ve bunu yaptıktan sonra eaccelerator'ın yükseltilmesi gerektiğini gördüm.

Sahip olduğum bir sunucuda da bu sorunu yaşadım ve temel neden APC idi. Php.ini dosyasındaki "apc.so" uzantısını yorumladım, Apache'yi yeniden yükledim ve siteler hemen geri geldi.

Yukarıdaki her şeyi denedim ve zend.enable_gc = 0 bana yardımcı olan tek yapılandırma ayarı.

Suhosin-Patch (cli) ile PHP 5.3.10-1ubuntu3.2 (inşa: 13 Haziran 2012 17:19:58)

PHP için Mongo 2.2 sürücüsünü kullanırken şu hatayı yaşadım:

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

^^ ÇALIŞMIYOR

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

^^ İŞLER! (?!)

PHP 5.3'te, çok fazla arama yaptıktan sonra benim için çalışan çözüm şuydu:

Bu sayfa için PHP çöp toplama özelliğini ekleyerek devre dışı bıraktım :

<? gc_disable(); ?>

tüm hataları ortadan kaldıran sorunlu sayfanın sonuna.

kaynak .

Bu soruna birçok nedenin neden olabileceğini düşünüyorum. Ve benim durumumda, 2 sınıfa aynı adı veriyorum ve biri diğerini yüklemeye çalışacak.

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

Ve benim durumumda bu soruna neden oluyor.

(Laravel çerçevesini kullanarak php artisan db: seed'i gerçek olarak çalıştırma)

Aynı sorunu yaşadım ve memcached oturumları için session.save_path için yanlış bir IP aldığımda. Doğru IP'ye değiştirmek sorunu çözdü.

Nitelikleri kullanıyorsanız ve özellik sınıftan sonra yüklendiyse (yani otomatik yükleme durumunda) özelliği önceden yüklemeniz gerekir.

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

Not: Bu hata çok çok rastgeledir; doğası gereği.

Benim için sorun pdo_mysql kullanıyordu. Sorgu, 1960 sonuçlarını döndürdü. 1900 kayıtları iade etmeye çalıştım ve işe yarıyor. Yani sorun pdo_mysql ve çok büyük bir dizi. Sorguyu orijinal mysql uzantısıyla yeniden yazdım ve işe yaradı.

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

Apache, önceki herhangi bir hatayı rapor etmedi.

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 bozuk" bellek yönetimi ile ilgili sorunlar anlamına gelir. Herhangi bir PHP modülünden kaynaklanabilir. Benim durumumda APC kurulumu işe yaradı. Teoride eAccelerator, XDebug vb. Gibi diğer paketler de yardımcı olabilir. Veya, bu tür modüller yüklüyse, onları kapatmayı deneyin.

Bir php uzantısı yazıyorum ve ayrıca bu sorunla karşılaşıyorum. Uzantımdan karmaşık parametrelere sahip bir harici işlev çağırdığımda bu hata çıkıyor.

Bunun nedeni, extern işlevinde bir parametre (char *) için bellek ayırmamam. Aynı tür bir uzantı yazıyorsanız, lütfen buna dikkat edin.

Benim için bellek sızıntısına neden olan ve MemoryManager'ın çökmesine neden olan ZendDebugger'dı.

Devre dışı bıraktım ve şu anda daha yeni bir sürüm arıyorum. Bulamazsam, xdebug'a geçeceğim ...

Buna bir çözüm bulamadığım için LAMP ortamımı yükseltmeye karar verdim. PHP 5.3.x ile Ubuntu 10.4 LTS'ye gittim. Bu benim için sorunu durdurmuş gibi görünüyor.

Benim durumumda, kodda aşağıdakileri unuttum:

);

Etrafta oynadım ve burada ve orada kodda unuttum - bazı yerlerde yığın bozulması var, bazı durumlarda sadece normal hata:

[08 Haz 17:23:21 2011] [not] çocuk pid 5720 çıkış sinyali Segmentasyon hatası (11)

Mac 10.6.7 ve xampp kullanıyorum.

Bu hatayı ve SIGSEGV'leri PHP 5.2+ ile çalıştırırken açıkça referansları zorlamak için '&' kullanan eski kodu çalıştırırken de fark ettim.

Ayar

assert.active = 0 

php.ini'de bana yardımcı oldu ( php5UTF8kitaplıktaki tür iddialarını kapattı ve zend_mm_heap corruptedgitti)

Benim için problem memcached artalan süreci çöktü, çünkü PHP oturum bilgilerini memcached içinde depolayacak şekilde yapılandırıldı. % 100 cpu yiyor ve tuhaf davranıyordu. Memcached sonrasında yeniden başlatma sorunu ortadan kalktı.

Diğer cevapların hiçbiri buna değinmediğinden, bu problemi php 5.4'te yanlışlıkla sonsuz bir döngü çalıştırdığımda yaşadım.

Bazılarına yardımcı olabilecek bazı ipuçları

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

var_dummp () kullanmak aslında bir hata değildir, sadece hata ayıklama için yerleştirilmiştir ve üretim kodundan kaldırılacaktır. Ancak zend_mm_heap'in gerçekleştiği gerçek yer ikinci sırada.

Burada da aynı durumdaydım, yukarıdaki hiçbir şey yardımcı olmadı ve daha ciddi bir şekilde kontrol etmekle sorunumu buldum, tampona bir çıktı gönderdikten sonra try do die (header ()) den ibaret, bunu Kod'da yapan adam CakePHP kaynaklarını unuttu ve basit bir "$ this-> yönlendirme ($ url) döndür" yapmadı.

Kuyuyu yeniden icat etmeye çalışırken sorun buydu.

Umarım bu, birine yardım eder!