Неустранимая ошибка PHP в номере строки, которая не существует

Question

Неустранимая ошибка : допустимый объем памяти 134217728 байт исчерпан (попытка выделить 523800 байт) в / Library / WebServer / Documents / XMLDataStore.class.php в строке 981

Любопытно, что эта ошибка не связана с утечкой памяти, которую легко устранить. Скорее, это тот факт, что XMLDataStore.class.php имеет длину всего 850 строк, что я проверял в нескольких текстовых редакторах.

Это с PHP 5.3 в комплекте со Snow Leopard. Я не использую кэш кода операции. Вот мой php.ini:

allow_url_fopen = Off
error_reporting = -1
display_errors = 1
display_startup_errors = 1
date.timezone = 'America/Los_Angeles'
output_buffering = Off
realpath_cache_size = 0k

XMLDataStore.class.php недавно был подвергнут рефакторингу и имел длину более 981 строки. Это почти как если бы PHP кэшировал 2-недельную версию и читает ее. Я уверен, что текущая версия в /Library/WebServer/Documents/XMLDataStore.class.php имеет длину всего 850 строк.

Answer 1

Может ли это быть проблемой разрыва строки? то есть интерпретатор PHP ломает строки иначе, чем ваш IDE / редактор? Я не знаю, как PHP обрабатывает переносы строк в Linux / Mac / Windows, но это может быть возможно. Можете ли вы создать фатальную ошибку где-нибудь в скрипте и посмотреть, какой номер строки он вам показывает?

Возможно, в вашем коде есть слишком длинные строки (> 65535 символов), которые смешивают счет строк?

Кроме того, что произойдет, если вы переименуете файл и включите его под новым именем? Это должно позаботиться о любых проблемах с кешем.

Answer 2

PHP Кажется, что есть проблемы с окончанием строки в стиле Macintosh, он не считает cr в конце комментариев. У меня была эта проблема после открытия файла на яблоке друзей. Я использовал kate в linux и Crimson Editor в Windows, чтобы изменить конец строки обратно на стиль Unix, и номера строк работали нормально.

Answer 3

Я также столкнулся с этой проблемой недавно, в моем случае (PHP 5.3 в Ubuntu / Nginix под php-fpm5) у меня был скрипт, который вызывал ошибку 500 без вывода (из-за того, что он был в работе). При проверке журнала ошибок он упоминал строку 589 в index.php, в которой количество строк доходило только до 453. В моем случае решением было отключить поддержку короткого тега в рабочей среде, но включить его для постановки ...

т. <? было отключено и <?php требовалось для открытия тегов PHP.

Ошибка в журнале, очевидно, не помогла в моем случае, поэтому мне потребовалось время, чтобы устранить ее. Я оставляю это предложение здесь, надеясь, что оно сэкономит кому-то время.

Answer 4

Хотя я понятия не имею, что может послужить причиной неправильного подсчета строк (я тоже использую PHP 5.3 на OSX 10.6. Здесь нет проблем.), Вы можете сузить реальную ошибку, разделив ваш скрипт на более мелкие части. таким образом, возможно, вы найдете реальное местоположение вашей ошибки.

И 850-строчный PHP-файл может серьезно использовать рефакторинг в любом случае.

Answer 5

Вот еще немного информации. Я пробовал один и тот же код на другом Mac, работающем под той же версией Snow Leopard - та, которая редко используется для разработки и не кэшировала версию этого файла - тот же результат.

Затем я попытался скопировать тот же код в коробку Solaris с PHP 5.2.8. Я все еще получаю ошибку памяти - что, конечно, нормально и ожидаемо, поскольку она существует - но вместо этого в сообщении об ошибке PHP говорится:

Неустранимая ошибка: достигнут максимальный уровень вложенности функции «100», прерывание! в /export/www/htdocs/XMLDataStore.class.php в строке 741

Это имеет смысл, поскольку это первая строка метода, которая вызывается рекурсивно другим методом. Точно такой же код с одинаковыми разрывами строк (LF) извлечен в одной и той же ревизии # из одного и того же хранилища SVN на всех 3 компьютерах.

Ошибка в PHP 5.3.0 для Snow Leopard? :)

Answer 6

Если вы получаете сообщение об ошибке в несуществующей строке, вполне возможно, что PHP кеширует ее. Может быть, попробуйте переименовать его, а затем выполнить.

Не уверен насчет Snow Leopard, но я использую его прямо сейчас и должен сказать, что в одной только ОС существует множество странных ошибок, может быть, так.

Я сталкивался с этой ошибкой раньше, когда я обращался к БД и сохранял информацию в массиве, оказалось, что я забыл, насколько велика БД, и когда она прошла МБ в стеке, я получил эту ошибку, и она остановилась. Если ситуация аналогична, используйте более трудоемкий подход, такой как соединение, получение линии / блока / чего-либо еще, затем вернитесь назад. Не проходите через все, сохраняйте все это, затем делайте что-то.

Проверьте это: Ошибка выделения памяти Drupal.org

Надеюсь, это поможет, не уверен, насколько все ясно. Может быть, показать части вашего сценария, чтобы понять, что может быть причиной этого.