Joomla - Allowed memory size of 1073741824 bytes exhausted - php

Question

My joomla website started to show following error
Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 78 bytes)
I know we can increase the memory limit using ini_set, but I believe it is not the correct way to solve this. Even though, if I set the memory limit to unlimited (-1), I will get an Internal Server Error. I am completely unaware about the recent activities on this site, as I am newly assigned to this task. I tried to disable some plugins and modules using DB. What I did is, just fetch the entries from _modules and _plugins with descending order of id and change the publish to 0. But nothing works. I am getting the same error (Fatal error: Allowed memory...). I tried to open the admin page, that is also not loading. Just showing a blank page.
Please help me to fix this. I am new to joomla

Answer 1

I don't believe you're going to receive a concise answer for this type of problem as it is far too broad. It sounds like you have a memory leak. See:
How to find which PHP script is leaking memory?
Diagnosing Memory Leaks - Allowed memory size of # bytes exhausted
Unfortunately, finding the cause of a memory leak is seldom a simple task. The two links above do provide some useful tips, namely placing calls to memory_get_usage and also the Xdebug extension.
Even if you weren't new to Joomla and more familiar with the code base, it probably wouldn't make solving this problem any easier.

Answer 2

Lets start with what that message is telling you.
PHP is saying I have successfully allocated a GIGABYTE of memory for this code to run with but I now need to allocate another 78 bytes but I cannot because I have reached my limit.
The part of that statement that should be shouting at you is Its already allocated a GIGABYTE of memory for this processing. That is just ridiculous.
Either as was suggested by #mistermartin some code is causing a memory leak or you have some code in the process that failed that is consuming ridiculously large amounts of memory
That message usually is associated with a stack trace telling you in which piece of code this error happened, and which piece of code called that, etc, etc.
Question: Does it always happen in the same piece of code? If so thats where you start looking.
I would start by looking through all the code in that stack trace, not just the particular script that actually broke the camels back so to speak. Work your way back through all the code that has been executed looking for something that has the potential to allocate hugh amounts of memory, arrays are a good place to start but they are not the only possibility.
I would personally copy the site ( complete with database ) to a test environment where you can either use a decent debugger to follow the code through an execution of the offending code.
If you cannot setup a debugger then at least in a test environment you can add some debugging code to tell you where and when memory starts to be consumed at this riduculous rate.

Answer 3

If you are looking for a way to fix this issue please follow the below methods. But it's not adviced to use it since it does not solve the issue you have with your program(code). You still should check why the memory is exhausted.
1 Using PHP Code
ini_set('memory_limit', '-1'); // This will take unlimited memory usage of server
Above method is not working for you as you say.
2 Using php.ini
Change the line in php.ini If your line shows 32M try 128M.
memory_limit = 128M ;
Maximum amount of memory a script may consume (128MB)
How to debug the code
Your program is consuming memory than it need. This can often happen in PHP if you have a loop that has run out of control and you are creating objects or adding to arrays on each pass of the loop. Check for infinite loops.
How to find which PHP script is leaking memory?

Answer 4

I am not too familiar with Joomla, but verified it redirects traffic through an index.php file similar to many other frameworks and apps. A decent first step to finding WHERE the leak is would be adding the following to the index.php file.:
function shutdown() {
$aError = error_get_last();
if ($aError["type"] == E_ERROR ) {
openlog("Fatal Error Shutdown Log: ", LOG_ODELAY, LOG_USER);
syslog(LOG_ERR, 'Message: ' . $aError['message'] . PHP_EOL);
syslog(LOG_ERR, "File: " . $aError['file'] . PHP_EOL );
syslog(LOG_ERR, "Line: " . $aError['line'] . PHP_EOL );
}
}
register_shutdown_function( 'shutdown' );
Check your syslog for the string "Fatal Error Shutdown Log:" and it should give you the specific location the memory leak is occurring. If Joomla has a more appropriate location to put this code, go for it. In theory shutdown functions will run no matter what. all this does is log only the fatal errors to your syslog. Memory errors are fatal errors. Good luck.

Answer 5

I have experienced a similar issue with ridiculously long SQL strings (inherited code was imploding a massive array into an IN condition). Log your SQL queries and check they dont exceed the max_allowed_packet (1GB)
http://dev.mysql.com/doc/refman/5.1/en/packet-too-large.html

Answer 6

You could start by enabling Joomla debugging. On Joomla 3 it's at the backend > global configuration > system > debug system
Then, on the front end of your site your template should give some debugging info.
I would start by looking for clues in the Profile Information and Memory Usage sections
Good luck!
Edit
Admittedly this is bit of a long shot, but maybe there are some Akeeba backups siting on the site that you could use. Look for some Akeeba .jpa files, probably in site_root/administrator/components/com_akeeba/backup/
If there are, I would start by restoring them to another machine so that you can rule out any server php related errors as well.
Maybe you'll be lucky.

Answer 7

I had this problem also - for my /administrator/ folder. None of the configuration or php.ini memory limit changes fixed the problem, which I tracked down to being connected to the fact that I'd changed the name of my /administrator/ folder in order to make it more difficult for hackers. Shouldn't have made a difference, if code was using relative paths, but apparently some code did not. Now, I rename the folder back to default to use admin features, then back to a random name to give the hackers a better challenge. So, have you changed any folder names??? I hope this helps someone.