1

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

laradev
  • 788
  • 1
  • 7
  • 21
  • Are you sure your configuration.php file matches all the specifications for your server? This includes the database settings, paths and `$live_site` variable – Lodder Aug 09 '14 at 16:33
  • @Lodder: yes, I made some intentional mistakes with DB setting and I got the corresponding error. Regarding the `$live_site`, I leave it as null for the time being – laradev Aug 09 '14 at 16:53
  • As suggested below, you need to do a few diagnostic things before trying any solutions. 1. Turn on all debugging and 2. Turn error reporting to "development." Within debugging try turning on everything. Is this happening on the front end and the backend just the same? What does your apache log say? Also your instinct to turn off all non core plugins is a good one, do that via the database. But only the non core ones. This is not about needing to increase you memory, I've seen this before as has everyone. – Elin Aug 14 '14 at 23:19
  • Also please give exact Joomla, PHP, and MySQL versions. – Elin Aug 14 '14 at 23:26

7 Answers7

5

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:

  1. How to find which PHP script is leaking memory?
  2. 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.

Community
  • 1
  • 1
mister martin
  • 5,746
  • 3
  • 24
  • 58
4

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.

RiggsFolly
  • 83,545
  • 20
  • 96
  • 136
  • It might also be useful to turn the limit *down* to something smaller, a reasonable amount that might be expected to be used, such as a megabyte or a few megabytes, so that you can see sooner where the excessive memory allocation is occurring. – David Conrad Aug 18 '14 at 17:35
2

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?

Community
  • 1
  • 1
Techie
  • 42,101
  • 38
  • 144
  • 232
1

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.

Jared Chmielecki
  • 439
  • 4
  • 13
1

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

Mike Miller
  • 2,686
  • 1
  • 18
  • 30
0

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.

-1

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.

David Taiaroa
  • 23,537
  • 7
  • 57
  • 48
  • It seems very unlikely to me that a permissions problem would result in PHP running out of memory. – duskwuff -inactive- Aug 12 '14 at 06:03
  • @duskwuff, re memory ... it seems unlikely to me as well. Information provided in the description is now completely different than 2 days ago when I first posted this suggestion – David Taiaroa Aug 12 '14 at 10:32