Вобщем есть php-скрипт, который запускается в CLI-режиме кроном. Скрипт работает около 3-х минут (добавляя данные в БД), после чего внезапно вылетает с ошибкой "Segmentation fault"
Гуглил, пишут, что надо настроить создание дампа во время падения и курить дамп. Проблема в том, что нет root доступа для того чтобы все это провернуть.
Есть у кого-нибудь идеи? Желательно, кто сталкивался с подобной проблемой.

---

Спустя 9 минут, 38 секунд Invis1ble написал(а):

---

Техподдержка хостинга очень уныла, я им месяца 3 назад двое суток доказывал, что в MySQL 5.1 баг и прилагал тест-кейс воспроизводящий проблему и просил обновить мускул. Они включали дурачка и писали что все норм. После 2-х суток согласились, что да, баг, но мускул обновлять не будут. Хостинг немецкий, кстати, вроде как популярный )

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Invis1ble
может с самим скриптом что то не так? Может где то нужно память высвобождать, чтоб не текла?

http://habrahabr.ru/company/bitrix/blog/153001/ ?

_____________
Свои мозги еще никто не отменял.
Телепатов нету.

killer8080
память вроде освобождаю, хотя надо бы проверить, да

waldicom
уже читал, стоит в закладках )

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Invis1ble
не смотрел в топе сколько процессорных ресурсов кушает скрипт? Возможно хостер автоматом киляет процессы длительно перегружающие цпу.

спасибо за комменты, попозже отпишусь о всех результатах наблюдений

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

сводка с фронтов:
в очередной раз запустив скрипт php успел выкинуть предсмертную ошибку, преобразованную в ErrorException и записанную в лог фреймворком (после записи в лог скрипт завершается exit'ом), после чего был убит с пресловутым Segmentation fault. Лог указывает на строку в парсере Simple HTML DOM с комментарием в коде:

    // clean up memory due to php5 circular references memory leak...
    function clear()
    {
        foreach ($this->nodes as $n) {$n->clear(); $n = null;} // тут была ошибка Call to a member function clear() on a non-object

Кажется, я вплотную подобрался к разгадке =)

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

в продолжение вот что накопал: http://kirugan.ru/2013/01/kak-borotsya-s-s...imple_html_dom/
щас буду колдовать

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Рекомендация сменить null на unset() никак не изменила ситуацию.

Я просто присваивал свойству, в котором была ссылка на объект simple_html_dom null:

$this->_dom = null;

Помог такой фикс:

if ($this->_dom instanceof simple_html_dom)
{
    $this->_dom->clear();
    $this->_dom = null;
}

А теперь, внимание, прикол:
деструктор simple_html_dom:

    function __destruct()
    {
        $this->clear();
    }

То есть simple_html_dom::clear() и так вызывался при $this->_dom = null
Спрашивается, WTF ??!!
c тем, что деструкторы в php работают криво, я уже сталкивался. Но чтоб такое.... :blink: :blink: :blink:

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Кстати, забыл отписаться о результатах мониторинга. Мониторил с помощью htop, отклонений в расходе памяти замечено не было ни до фикса, ни после... Правда после фикса стал кушать немножко поменьше, но все в пределах разумного... Есть предположение, что утечка носила лавинообразный характер, из-за чего данные в htop не успевали обновиться до убийства процесса.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль