Ошибка PHP / Apache в скрипте (ошибка сегментации (11)

[Решено]

Я запускаю PHP-скрипт (с некоторыми включенными) на localhost, который продолжает сбой до конца.

Сообщение об ошибках включено. Opera, Safari и Firefox возвращают пустой экран. Но Chrome возвращается:

Не удалось загрузить веб-страницу, потому что сервер не отправил данные. Код ошибки: ERR_EMPTY_RESPONSE

Журналы Apache возвращаются:

[Sun Dec 15 19:29:23 2013] [уведомление] child pid 34267 сигнал выхода Ошибка сегментации (11)

Я использовал PHP 5.5.6, когда впервые столкнулся с проблемой. После переопределения на PHP 5.4.21 проблема все еще существует.

Проблема не в скрипте. Случайно комментируя пару из 50 строк кода, решает проблему. Заставить меня задаться вопросом, может ли мой сценарий работать долго.

У кого-нибудь есть предложения по тому, как я могу решить эту проблему?

ОБНОВИТЬ:

Проблема возникает не только на локальном хосте, но и на моем веб-сервере, работающем на CentOs 6.4 и PHP 5.3.3, дающем ту же ошибку в Apache.

[Sun Dec 15 23:15:10 2013] [уведомление] child pid 18409 сигнал выхода Ошибка сегментации (11)

UPDATE2:

Запуск php из командной строки дает:

$ php index.php Неустранимая ошибка: вызов неопределенной функции mcrypt_create_iv () в Encrypt.class.php в строке 135

После размещения комментария до строки 135 на Encrypt.class.php

$ php index.php
Ошибка сегментации: 11

UPDATE3: (решение)

После запуска индекса в командной строке с strace (strace php index.php) я нашел проблему в одном из запросов.

После некоторой дополнительной отладки (используя PDO вместо моего собственного класса) я выяснил, что проблема заключалась в установке моей собственной опции PDO «ATTR_PERSISTENT => true». Отключение этой опции решило мою проблему.

UPDATE3: (решение)

Вариант Persisten PDO очень сильно нарушил мою работу.

Нашел решение с strace: после запуска индекса в командной строке с strace (strace php index.php) я нашел проблему в одном из запросов.

После разделения запроса я заменил свой класс PDO по умолчанию. Добавление параметров моего класса до тех пор, пока он не был сломан снова: после некоторой дополнительной отладки (используя PDO вместо моего собственного класса) я выяснил, что проблема заключалась в установке моей собственной опции PDO «ATTR_PERSISTENT => true». Отключение этой опции решило мою проблему.