Раптом у мене виникли проблеми з моїм додатком, яких я ніколи раніше не мав. Я вирішив перевірити журнал помилок Apache, і знайшов повідомлення про помилку із повідомленням "zend_mm_heap пошкоджений". Що це означає.

ОС: Fedora Core 8 Apache: 2.2.9 PHP: 5.2.6

Після багатьох проб і помилок я виявив, що якщо збільшити output_bufferingзначення у файлі php.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;
}

Код, описаний вище, може бути складений за допомогою:

gcc -g -o corrupt corrupt.c

Виконуючи код з valgrind, ви можете бачити багато помилок пам'яті, що досягає помилки сегментації:

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

Якщо ви не знали, ви вже зрозуміли, що memце пам'ять, виділена купу; Купа посилається на область пам’яті, доступну програмі під час виконання, тому що програма явно вимагала цього (у нашому випадку з malloc).

Якщо ви пограєте зі страшним кодом, то виявите, що не всі ці явно неправильні твердження призводять до помилки сегментації (фатальної помилки закінчення).

Я явно робив ці помилки в прикладі коду, але такі самі помилки трапляються дуже легко в середовищі, керованої пам'яттю: Якщо якийсь код не підтримує перерахунок змінної (або якогось іншого символу) правильним чином, наприклад якщо це безкоштовно, це занадто рано, інший фрагмент коду може прочитати з уже вільної пам’яті, якщо він якось невірно зберігає адресу, інший фрагмент коду може записати в недійсну пам’ять, він може безкоштовно два рази ...

Це не проблеми, які можна налагодити в PHP, вони абсолютно вимагають уваги розробника внутрішніх справ.

Хід дії повинен бути:

1. Відкрийте звіт про помилку на http://bugs.php.net
   • Якщо у вас є сегмент за замовчуванням, спробуйте створити зворотній шлях
   • Включіть стільки інформації про конфігурацію, скільки здається доцільною, зокрема, якщо ви використовуєте opcache, включайте рівень оптимізації.
   • Продовжуйте перевіряти звіт про помилку щодо оновлень, більше інформації може знадобитися.
2. Якщо у вас завантажений опкаш, вимкніть оптимізацію
   • Я не вибираю на оптике, це чудово, але деякі оптимізації, як відомо, спричиняють помилки.
   • Якщо це не працює, хоча ваш код може бути повільнішим, спробуйте спочатку розвантажити опкаш.
   • Якщо щось із цього зміниться або виправить проблему, оновіть зроблений вами звіт про помилку.
3. Вимкніть одразу всі непотрібні розширення.
   • Почніть активувати всі розширення окремо, ретельно протестуючи після кожної зміни конфігурації.
   • Якщо ви знайдете розширення проблеми, оновіть звіт про помилку, отримавши більше інформації.
4. Прибуток.

Можливо, прибутку не буде ... Я сказав, що на початку ви, можливо, зможете знайти спосіб змінити свої симптоми, змішавшись із конфігурацією, але це надзвичайно вражає і пропускає, і це не допоможе наступного разу, коли у вас буде те саме zend_mm_heap corruptedповідомлення, існує лише стільки варіантів конфігурації.

Дійсно важливо, що ми створюємо звіти про помилки, коли знаходимо помилки, ми не можемо припустити, що наступна людина, яка потрапила на помилку, це зробить ... скоріше, ніж ні, фактичне рішення ні в якому разі не таємниче, якщо ви зробите потрібні люди, обізнані про проблему.

USE_ZEND_ALLOC

Якщо ви встановите USE_ZEND_ALLOC=0в оточенні, це відключає власний диспетчер пам'яті Зенда; Менеджер пам’яті Zend гарантує, що кожен запит має власну купу, що вся пам'ять вільна, в кінці запиту, і оптимізована для розподілу шматочків пам'яті саме потрібного розміру для PHP.

Якщо вимкнути його, вимкніть ці оптимізації, що ще важливіше, це, швидше за все, створить витоки пам’яті, оскільки існує дуже багато коду розширення, який покладається на Zend MM для звільнення для них пам’яті в кінці запиту (tut, tut).

Це також може приховати симптоми, але системна купа може бути пошкоджена точно так само, як і купа Зенда.

Це може здатися більш толерантним або менш толерантним, але виправити першопричину проблеми вона не може .

Можливість взагалі відключити це - на благо розробників внутрішніх справ; Ніколи не слід розгортати PHP з відключеним Zend MM.

Я отримував цю саму помилку під PHP 5.5, і збільшення вихідної буферизації не допомогло. Я не запускав APC, так що це не було проблемою. Нарешті я простежив його до опкаш , я просто мусив відключити його із клі. Для цього було визначено конкретні налаштування:

opcache.enable_cli=0

Після переключення zend_mm_heap пошкоджена помилка пішла.

Якщо ви знаходитесь у вікні Linux, спробуйте це в командному рядку

export USE_ZEND_ALLOC=0

Перевірте на unset()с. Переконайтеся, що ви не unset()посилаєтесь на $this(або їх еквіваленти) в деструкторах, і цеunset() s в деструкторах не призводять до того, що кількість посилань на один і той же об'єкт знижується до 0. Я провів деякі дослідження і виявив, що це зазвичай викликає купу корупція.

Існує звіт про помилку PHP про пошкоджену помилку zend_mm_heap . Дивіться коментар[2011-08-31 07:49 UTC] f dot ardelian at gmail dot com для прикладу, як відтворити його.

У мене таке відчуття, що всі інші "рішення" (змінити php.ini, скласти PHP з джерела з меншими модулями тощо) просто приховують проблему.

Для мене жодна з попередніх відповідей не спрацювала, поки я не спробував:

opcache.fast_shutdown=0

Це, здається, працює поки що.

Я використовую PHP 5.6 з PHP-FPM та Apache proxy_fcgi, якщо це має значення ...

У моєму випадку причиною цієї помилки було те, що один з масивів стає дуже великим. Я встановив свій сценарій для скидання масиву на кожній ітерації, і це сортувало проблему.

Відповідно до трекера помилок, встановіть opcache.fast_shutdown=0. Швидке відключення використовує диспетчер пам'яті Zend, щоб очистити його безлад, це вимикає це.

Я не думаю, що тут є одна відповідь, тому я додам свій досвід. Я бачив цю саму помилку разом із випадковими httpd segfault. Це був сервер cPanel. Симптом, про який йдеться, був у тому, що апач випадково скине з'єднання (відсутні дані, отримані в хромі, або з'єднання не було скинуто у Firefox). Це були, здавалося б, випадкові - більшість часу це працювало, іноді - не.

Коли я приїхав на сцену, буферизація виходу була вимкнена. Читаючи цей потік, який натякав на буферизацію виводу, я включив його (= 4096), щоб побачити, що буде. У цей момент всі вони почали показувати помилки. Це було добре, що помилка тепер повторюється.

Я пройшов і почав вимикати розширення. Серед них еакцелератор, pdo, навантажувач ioncube та багато іншого, що виглядало підозріло, але жодне не допомогло.

Нарешті я знайшов неслухняне розширення PHP як "homeloader.so", яке, схоже, є якимось модулем cPanel, який легко встановлюється. Після видалення жодних інших проблем у мене не виникло.

З цієї замітки, здається, це загальне повідомлення про помилку, тому ваш пробіг буде відрізнятися залежно від усіх цих відповідей, найкращий спосіб дії, який ви можете вжити:

• Кожен раз робіть помилку, що повторюється (в яких умовах?)
• Знайдіть загальний фактор
• Вибірково відключіть будь-які модулі, параметри PHP та ін. (Або, якщо ви поспішаєте, відключіть їх усіх, щоб побачити, чи це допомагає, а потім вибірково повторно ввімкніть їх, доки він знову не зламається)
• Якщо це не допоможе, багато з цих відповідей натякають на те, що його можна скасувати. Знову ж таки, головне - зробити помилку, що повторюється кожен запит, щоб ви могли її звузити. Якщо ви підозрюєте, що код цього робить, ще раз, після помилки, яку можна повторити, просто видаліть код, поки помилка не припиниться. Як тільки він зупиняється, ви знаєте винуватець останнього фрагменту коду.

Якщо все вищесказане не вдалося, ви також можете спробувати такі речі, як:

• Оновлення або перекомпіляція PHP. Сподіваємось, що будь-яка помилка викликає вашу проблему, виправлена.
• Перемістіть свій код в іншому (тестовому) середовищі. Якщо це вирішує проблему, що змінилося? Параметри php.ini? Версія PHP? тощо ...

Удачі.

Я боровся з цим питанням протягом тижня. Це працювало на мене, або принаймні так здається

В php.iniзробити ці зміни

report_memleaks = Off  
report_zend_debug = 0  

Моя установка така

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

Це не спрацювало.

Тому я спробував використати орієнтир-орієнтир і спробував записати, де сценарій завис. Я виявив, що безпосередньо перед помилкою, об'єкт php був екземпляром, і для того, щоб виконати те, що повинен був зробити об'єкт, знадобилося більше 3 секунд, тоді як у попередніх циклах максимум 0,4 секунди. Я пройшов цей тест досить багато разів, і кожен раз те саме. Я думав, що замість того, щоб робити новий об’єкт кожного разу, (тут довгий цикл), я повинен використати об'єкт повторно. Я перевіряв сценарій вже не один десяток разів, і помилки пам'яті зникли!

Шукайте будь-який модуль, який використовує буферизацію, і вибірково відключайте його.

Я запускаю PHP 5.3.5 на CentOS 4.8, і після цього я виявив, що еакцелератор потребує оновлення.

У мене якраз була ця проблема і на власному сервері, і першопричиною була APC. Я прокоментував розширення "apc.so" у файлі php.ini, перезавантажив Apache, і сайти повернулися до резервного копіювання.

Я спробував усе вище і zend.enable_gc = 0- єдине налаштування конфігурації, яке мені допомогло.

PHP 5.3.10-1ubuntu3.2 з Suhosin-Patch (cli) (побудовано: 13 червня 2012 17:19:58)

У мене виникла помилка під час використання драйвера Mongo 2.2 для PHP:

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

^^ НЕ РОБОТИ

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

^^ РОБОТИ! (?!)

На PHP 5.3 після пошуку лотів це рішення, яке працювало для мене:

Я відключив збір сміття PHP для цієї сторінки, додавши:

<? gc_disable(); ?>

до кінця проблемної сторінки, яка змусила всі помилки зникнути.

джерело .

Я думаю, що багато причин можуть викликати цю проблему. І в моєму випадку я називаю 2 класи з однаковою назвою, і один спробує завантажити інший.

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

І це викликає цю проблему в моєму випадку.

(Використовуючи Laravel Framework, запускаючи php artisan db: насіння в реальному)

У мене був цей самий випуск, і коли у мене був неправильний IP-адресу для session.save_path для сеансів, що запам'ятовуються. Змінивши його на правильний IP виправили проблему.

Якщо ви використовуєте ознаки, і ознака завантажується після класу (тобто випадку автозавантаження), потрібно заздалегідь завантажити його.

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

Примітка: ця помилка дуже випадкова; завдяки своїй природі.

Для мене проблемою було використання pdo_mysql. Запит повернув 1960 результати. Я намагався повернути 1900 записів, і це працює. Отже, проблема - pdo_mysql і занадто великий масив. Я переписав запит з оригінальним розширенням mysql, і він спрацював.

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

Apache не повідомляв про жодні попередні помилки.

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 пошкоджений" означає проблеми з управлінням пам'яттю. Може бути викликано будь-яким модулем PHP. У моєму випадку встановлення APC спрацювало. Теоретично можуть допомогти й інші пакети, такі як eAccelerator, XDebug тощо. Або якщо у вас встановлені такі модулі, спробуйте вимкнути їх.

Я пишу розширення для php, а також стикаюся з цією проблемою. Коли я викликаю зовнішню функцію зі складними параметрами з мого розширення, ця помилка спливає.

Причина в тому, що я не виділяю пам'ять для параметра (char *) у функції extern. Якщо ви пишете таке ж розширення, зверніть увагу на це.

Для мене саме ZendDebugger спричинив протікання пам’яті і спричинив аварію MemoryManager.

Я його відключив, і зараз шукаю нову версію. Якщо я не можу його знайти, я перейду до xdebug ...

Оскільки я так і не знайшов рішення для цього, я вирішив модернізувати своє середовище LAMP. Я перейшов на Ubuntu 10.4 LTS з PHP 5.3.x. Здається, це зупинило проблему для мене.

У моєму випадку я забув наступне в коді:

);

Я розігрував і забув це в коді тут і там - у деяких місцях я купив корупцію, в деяких випадках просто ясна помилка:

[Ср. Черв. 08, 17:23:21 2011] [повідомлення] дочірній сигнал 5720 сигнал виходу. Помилка сегментації (11)

Я на Mac 10.6.7 і xampp.

Я також помітив цю помилку та SIGSEGV під час запуску старого коду, який використовує "&" для явного примусового використання посилань під час його запуску в PHP 5.2+.

Налаштування

assert.active = 0 

в php.ini допоміг мені (він вимкнув твердження типу в php5UTF8бібліотеці і zend_mm_heap corruptedпішов)

Для мене проблемою був збій мемованного демона, оскільки PHP був налаштований для зберігання інформації про сеанс у memcached. Він їв 100% процесор і діяв дивно. Після запам’ятовування перезавантаження проблема пішла.

Оскільки жоден з інших відповідей на нього не вирішився, у мене була проблема в php 5.4, коли я випадково запустив нескінченний цикл.

Деякі поради, які можуть допомогти комусь

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 () фактично не є помилкою, він розміщується просто для налагодження і буде видалений у виробничому коді. Але справжнє місце, де сталося zend_mm_heap, - це друге місце.

Я опинився в цій самій ситуації, нічого вище не допомогло, і перевіряючи більш серйозно, я знаходжу свою проблему, вона полягає в try do die (header ()) після надсилання деякого виводу в буфер, людина, яка зробила це в кодексі, забула про ресурси CakePHP і не робив симплетів "return $ this-> redirect ($ url)".

Спробуючи знову винайти колодязь, це була проблема.

Я сподіваюся, що ця стаття допоможе комусь!