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 the memory leak, which would be easy enough to troubleshoot. Rather, it is the fact that XMLDataStore.class.php is only 850 lines long, which I have verified in multiple text editors.
This is with the PHP 5.3 bundled with Snow Leopard. I'm not using an opcode cache. 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
XMLDataStore.class.php has recently been refactored and it used to be longer than 981 lines. It's almost as if PHP has cached a 2-week-old version and is reading that. I'm positive that the current version at /Library/WebServer/Documents/XMLDataStore.class.php is only 850 lines long, though.
Could this be a line break issue? i.e. the PHP interpreter breaking lines differently than your IDE / editor? I don't know about how PHP handles Linux/Mac/Windows linebreaks, but it might be a possibility.
Can you create a fatal error somewhere in the script, and look which line number it shows you?
Could there be some over-long lines in your code (> 65535 characters) that mix up the line counting?
Also what happens if you rename the file, and include it under a new name? THis should take care of any screwed up cache issues.
PHP Seems to have issues with macintosh style line ending, It doesnt count the cr at the end of comments. I had this issue after opening a file on a friends apple.
I used kate on linux and Crimson Editor on Windows to change the end of line back to Unix style and the line numbers worked fine.
If you are getting an error on a non-existant line then it may very well be that PHP is caching it.
Maybe try renaming it then executing it.
Not to sure about Snow Leopard, but I am using it right now and have to say there are a great deal of strange bugs with the OS alone, could be that.
I experienced this error before when I was accessing a DB and storing info in an array, turns out I forgot how large the DB was and when it passed MB on the stack I got that error and it stopped.
If the situation is similar use a more processor heavy approach, such as connect, get a line/ block/ whatever, to something, then go back.
Don't go through everything, store it all, then do something.
Check this out:
Drupal.org memory allocation error
Hope this helps, not sure how clear all of this is.
Maybe show parts of your script to get an idea of what might be causing this.
Here is some more info. I tried the same code on a different Mac running the same version of Snow Leopard - one that is rarely used for development and would not have a version of this file cached - same result.
Next I tried copying the same code to a Solaris box running PHP 5.2.8. I still get the memory error - which is fine and expected, of course, since it does exist - but the PHP error message says this instead:
Fatal error: Maximum function nesting level of '100' reached, aborting! in /export/www/htdocs/XMLDataStore.class.php on line 741
This makes perfect sense, as that is the first line of a method that is being called recursively by another method. Exact same code with same line breaks (LF) checked out at the same revision # from the same SVN repository on all 3 machines.
Bug in PHP 5.3.0 for Snow Leopard? :)
While I have no idea what may cause this wrong line counting (I'm using PHP 5.3 on OSX 10.6, too. No Problems here.), you can narrow down the actual error by dividing your script into smaller parts.
that way maybe you'll find the real location of your error.
And a 850 line PHP file could seriously use some refactoring anyway.
I was experiencing this issue as well recently, in my case (PHP 5.3 on Ubuntu/Nginix under php-fpm5) I had a script that was causing a 500 error with no output (due to it being on production). When examining the error log it mentioned line 589 on index.php which only had lines going up to 453. The solution in my case was support for the short tag was disabled on production but enabled for staging...
ie. <? was disabled and <?php was required for opening PHP tags.
The error in the log was obviously not helpful in my case so it took a while for me to troubleshoot it. I am leaving this suggestion here hoping it will save someone some time.
Related
Today when I tried to edit my site on local I got strange error like this :
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried
to allocate 6874029536211531203 bytes) in
D:\wamp64ario\www\owjgraph\wp-includes\functions.php on line 5231
Why it tried to allocate for 6874029536211531203?
Sometimes I get this when I try to reach Login Page, other times in different situations like dashboard or update posts etc.
I tried many things but no success:
My other website in local (with no plugins or various plugins) get the same error.
Increased memory_limit to 256, 512 or 1GB in WAMP but no success.
I heard version 4.9.7 have some memory leak bug so I downgraded to older versions and problem still exists.
Uninstall and reinstall WAMP.
Install other local tools like MAMP.
Clear cache and cookies and use different browser
Install fresh WordPress 4.9.7, 4.9.5 and 4.9.1
None of them solved my problem and I'm really confused.
Is this something wrong with my Windows or registry? How can I debug or trace where this problem is coming from?
Try: Look in your error logs, you may get a trace that will zero in on the problem for you (like an infinite loop).
Locate the line that is throwing the error & determine if it can be refactored to avoid the memory usage.
You can override php's memory allocation in your wp-config, like so:
define( 'WP_MAX_MEMORY_LIMIT' , '512M' ); but this is just a bandaid in my opinion. There is likely something wrong, which you'll need to fix for the long term health of your application.
The same thing is happening to me. If I var_dump stream_get_wrappers() I get weird results with very long lines of gibberish text. I think it's WAMP's fault, because I also get this error in plain php.
Temporary solution for WordPress:
Open wordpress/wp-includes/functions.php and modify wp_is_stream function to look like this:
function wp_is_stream( $path ) {
$wrappers = stream_get_wrappers();
for ($i=0;$i<count($wrappers);$i++) {
if (strlen($wrappers[$i])>100) {
unset($wrappers[$i]);
}
}
$wrappers_re = '(' . join('|', $wrappers) . ')';
return preg_match( "!^$wrappers_re://!", $path ) === 1;
}
I use WampServer 3.0.6 64bit
I'm a system administrator which handles a server that hosts an internal api created using Laravel 5. The data source is a SQL Server hosted on another server and the api is used in a IOS app for mobile phones. When the developers created the api, this error was not present and no other memory errors were found. When we went live this error has been popping up from time to time.
[2015-06-01 23:01:52] production.ERROR: exception 'Symfony\Component\Debug\Exception\FatalErrorException' with message 'Out of memory (allocated 262144) (tried to allocate 140189808036120 bytes)' in Unknown:0
I checked RAM, CPU, swap etc etc of the server but everything was ok. Not much of the resources are being consumed. I've checked PHP Memory limit from php.ini and is set to -1 which is the max according to PHP. I've checked it on CLI, phpinfo.php and httpd.conf I don't see anything wrong. The team tried following this link Allowed memory size of X bytes exhausted
This is a problem in the ios app because the app searches for a correct return code but when this error comes out, even if the ios app transaction is correct, it returns an error because the return code is incorrect as it is returning the code for the memory error.
The first thing I could think of was to restart the Apache httpd service. This immediately solved the issue. but I knew this is not a permanent fix for the issue. When I researched further, I got to know that the error comes when certain PHP scripts require more memory than PHP was allowed by default.
So the solution is to increase the memory allocated for PHP. How to do that? There are 4 possible ways –
Try looking for the php.ini file. You might find some redundant php.ini files, so make sure you have got the one which is actually being read by PHP. o be sure, create a new php file in your root folder, say “check.php” and have phpInfo(); within the php open and close tags. Execute this file to get the information on where the php.ini is residing. Normally it will be in /usr/local/lib/php.ini
Open the php.ini file in a text editor like TextPad (not in Notepad) and change the values for memory_limit. By default you should see memory_limit = 8M. Try changing it to 12M. If it doesn’t work, increase it to 16M or even 24M and so on.
In case you can’t find the php.ini file or do not have access to it, then open up the file which was throwing the error (admin.php in my case) and add a line below just after ini_set(’memory_limit’, ‘12M’);
You can even consider adding a line in .htaccess file which will resolve the issue.
php_value memory_limit 32M
Or else, Try adding this line to your php file:
Increasing memory allocated to PHP
ini_set(“memory_limit”,”16M“);
The problem is very very weird. Let me explain a little bit better - We have a multi site built for the client. Until recently we could edit the homepage with no issues. In the meantime we have upgraded the core (it was still working with new core). Just recently whenever I try to edit the homepage I get this error
Fatal error: Out of memory (allocated 42467328) (tried to allocate 64 bytes) in /home/officete/public_html/wp-includes/wp-db.php on line 1557
Ok so the apparent solution was to change the php memory allowance... Well I have increased it on the server via WHM, increased it in htaccess, wp-config and php.ini file to over 1.2GB (never really expected I will have to increase it so much) just for testing reasons. Every time I try to edit the page I get the same god damn error and 42467328 allocation limit doesn't change at all the " 64 bytes" part does though and its between 32-128 bytes so far.
I am stumped. And have no idea what else I can do. I did contact the server provider they say it looks ok from their end.
I am assuming its the amount of data that is being collected it does contain few ACF repeater fields (15 of them... I know... But I haven't built it). I did disable all the plugins the error persists (I know that disabling them don't really change what is being pulled from db).
BTW The line 1557 is the return result function that returns the query in an array.
you page need more execution time.add below code into config file and try:
define('WP_MEMORY_LIMIT', '128M');
I'm making a curl request , witch was working perfectly for weeks, and now it's returning this error:
Allowed memory size of 262144 bytes exhausted (tried to allocate 76889 bytes)
The weird part is that i've checked php.ini and phpinfo and both tell me memory limit is
memory_limit 1028M
I've also tried
ini_set("memory_limit","400M");
In the top of the file to make sure, but still, getting this error.
This is happening in both development and production servers.
DaveRandom nailed it. suhosin (I wasn't even aware we had that
installed) was causing de issue by "overprotecting" the server.
[forums.cpanel.net/f5/php-memory-limit-problem-69715.html][1] - TL;DR
it's being caused by suhosin. – DaveRandom
Thanks to all!
[1]: http://forums.cpanel.net/f5/php-memory-limit-problem-69715.html
UPS, that somehow fiexd the error in that part, but another part of the webapp is throwing same error.
I have no clue where to look at.
it says memory limit is 1028M in php info, if i change it via ini_set, new value appears using ini_get, and now I have set suhosin to simulation. that somehow fixed the first problem, but now it reappeared.
I have an import-from-excel script as part of a CMS that previously ran without issue.
My shared-hosting provider has recently upgraded their infrastructure, including PHP from 5.1 to 5.2.6, and the script now returns "Uninitialized string offset: -XXX in /path/scriptname.php on line 27" (XXX being a decreasing number from 512 and /path/scriptname.php of course being the full path to script in question).
It returns this error for every line of the excel file. Line 27 is just a return from within a function that is the first point at which the imported data is being processed:
function GetInt4d($data, $pos) {
return ord($data[$pos]) | (ord($data[$pos+1]) << 8) | (ord($data[$pos+2]) << 16) | (ord($data[$pos+3]) << 24);
}
It finally implodes with a "Fatal error: Allowed memory size of 47185920 bytes exhausted (tried to allocate 71 bytes) in /path/scriptname.php on line 133".
There's nothing useful in Apache error logs. I am stumped. Anyone have any ideas of at least where to look? Even knowing if it's likely to be something within my script or something to do with upgrade would be useful. I had another issue with a different site on same provider that (after upgrade) couldn't write sessions to tmp directory (since resolved), but am pretty sure it's not that (?).
EDIT: As it turned out that the answer was to do with the version of the parser being incompatible in some way with PHP 5.2.6, I thought it might be of use to someone that the parser in question is Spreadsheet Excel Reader .
Solved here:
http://www.phpbuilder.com/board/archive/index.php/t-10328608.html
Uninitialized string offset:
... means that $data is not an array.
Thanks for the input, the situation has 'resolved itself' via me finding a more recent version of the parsing library I was using. My guess is the issue was something to do with the difference between php versions, though I'm unsure exactly what. Fixed but frustrating.
EDIT: I'm going to accept Till's answer purely in the interests of closing the question. Thx again for input.