PHP Fatal error on line number that does not exist

Question

Fatal error : allowed memory size of 134217728 bytes exhausted (tried to allocate 523800 bytes) in /Library/WebServer/Documents/XMLDataStore.class.php on line 981

The curious thing about this error is not a memory leak that would be easy enough to troubleshoot. Rather, it is a fact that XMLDataStore.class.php is only 850 lines long, which I checked with several text editors.

This is with PHP 5.3 bundled with Snow Leopard. I do not use the operation cache code. Here is my 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 

Recently, XMLDataStore.class.php has been reorganized and it has been longer than 981 lines. It is almost as if PHP cached a 2-week version and reads it. I am sure that the current version in /Library/WebServer/Documents/XMLDataStore.class.php is only 850 lines.

Answer 1

Could this be a line break problem? those. PHP interpreter breaks lines differently than your IDE / editor? I don't know how PHP handles linux / mac / windows linear streams, but it might be possible. Can you create a fatal error somewhere in the script and see what line number it shows you?

Could there be some long lines in your code (> 65535 characters) that mix the line count?

And what happens if you rename the file and include it under a new name? This should take care of any cache issues.

Answer 2

PHP seems to have problems completing the macintosh style line, it does not consider cr at the end of the comments. I had a problem after opening a file on friends apple. I used kate for linux and Crimson Editor for Windows to change the end of the line to Unix style and the line numbers worked fine.

Answer 3

If you get an error on a non-existent line, it is possible that PHP caches it. Perhaps try renaming it, then doing it.

Not sure about Snow Leopard, but I'm using it right now and I have to say that there are a lot of weird bugs with the same OS, maybe it is.

I experienced this error before, when I accessed the database and stored the information in an array, it turns out I forgot how big the database is and when it passed the MB to the stack, I got this error and stopped. If the situation is similar, use a stronger processor approach, for example, connect, get a line / block / something, something, and then return. Do not worry everything, save everything, and then do something.

Check it out: Drupal.org memory allocation error

Hope this helps, but not sure how clear all of this is. Perhaps show parts of your script to understand what might be causing this.

Answer 4

Here is some more information. I tried the same code on another Mac with the same version of Snow Leopard, which is rarely used for development and will not have a version of this cached file - the same result.

Next, I tried to copy the same code into the Solaris box with PHP 5.2.8. I am still getting a memory error - this is normal and expected, of course, since it exists, but the following is said in the PHP error message:

Fatal error: the maximum level of nesting of the function "100" has been reached, is interrupted! in /export/www/htdocs/XMLDataStore.class.php on line 741

This makes sense since this is the first line of a method that is recursively called another method. The exact same code with the same line breaks (LF) is output in the same revision # from the same SVN repository on all three machines.

Error in PHP 5.3.0 for Snow Leopard? :)

Answer 5

While I have no idea what could lead to a wrong line count (I use PHP 5.3 on OSX 10.6 too. No problem here.), You can narrow down the actual error by splitting your script into smaller parts, maybe you will find the real location of your mistakes.

And an 850-line PHP file can seriously use some kind of refactoring.

Answer 6

I also ran into this problem recently (in my case (PHP 5.3 on Ubuntu / Nginix under php-fpm5) I had a script that caused a 500 error without output (due to the fact that it was in production). When viewing the log of errors, line 589 on index.php was mentioned, which had only lines rising to 453. The solution in my case was support so that the short tag would be disabled during production, but allowed for the stage ...

t. <? disabled, and <?php is required to open PHP tags.

The error in the log, obviously, did not help me in this case, so it took me a while to fix it. I leave this sentence here, hoping that he will save someone.