wordpress Fatal error: Allowed memory size (weird) - php

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

Related

Fatal error in WordPress, "Allowed memory size of X bytes exhausted"

I am a WordPress beginner and I have only rudimentary knowledge about CSS and HTML. I have built a WordPress blog in the last days, and it was working well. But since two days I couldn't login and couldn't open the page (but I haven't touch the page since about one week, I don't know what happened). This is what was shown:
Fatal error: Allowed memory size of 50331648 bytes exhausted (tried to allocate 30720 bytes) in /home/u0087038969/public_html/wp-admin/includes/deprecated.php on line 533
I suggested that one of the installed plugins caused this trouble. That's why I changed the name of the plugin file via FileZilla, so that I get access to WordPress again. Then I tried to reactivate the plugins gradually to find the trouble-maker. Still it's not really working. What can I do to go about solving the problem?
p.s. I used the following wp plugins: mail poet, all in one seo and contact form 7.
The problem is your installation is requiring more memory than you have available for your site. If you are using a shared hosting environment, you might be at a loss in increasing your memory allotment.
Try updating your wp-config file:
define('WP_MEMORY_LIMIT', '256MB');
If you can change your PHP.ini file you can adjust this:
php_value memory_limit 256MB
Your host seems to have this set incredibly low if it's giving you a memory error at 50MB.

Joomla 3.3.3 error after logout

I need to install Joomla on a webserver - first, I wasn't able to install Joomla on my remote webserver, because the installation wasn't able to complete step 1 (don't know why), so I installed it on my local computer and uploaded the finished installation on my webserver. So, everything was fine and I now I have a "working" joomla on my webserver.
BUT: I can log in with my admin username and password and so on, but when I click "logout" I get a blank page, only an empty body-tag.
Looking at the error.log file:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 3094558001 bytes) in [...]/www/libraries/joomla/filter/input.php on line 706
Everytime I want to open the start page, this error is appending to the log file. I googled and searched stackoverflow, but dind't find any solution.
The allowed memory size of this webserver seems to be 128MB, and the script wants to allocate about 3GB? For me this looks like the joomla developers did a bad job here, but I don't know. The funny thing is, when I google that error message, there are a lot ( ! ) of websites that are not working because of that error.
Please help me!
OK I just commented out the few lines of code there and it seems that everything works fine now. So if somebody has the same problem as me, just comment out that few lines and hopefully it works too!
Lines 702-713
// Convert decimal
/*$source = preg_replace_callback('/&#(\d+);/m', function($m)
{
return utf8_encode(chr($m[1]));
}, $source
);
// Convert hex
$source = preg_replace_callback('/&#x([a-f0-9]+);/mi', function($m)
{
return utf8_encode(chr('0x' . $m[1]));
}, $source
);*/

Wordpress Dies When trying to edit the homepage

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');

memory limit in php

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.

PHP Fatal error on line number that doesn't exist

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.

Categories