PHP “Fatal error: Allowed memory size of 8388608 bytes exhausted” solved
Posted on July 26, 2006
Filed Under /dev/null/ | 234 views |
Late yesterday afternoon, after I installed a PHP app we’re building onto one of our testing machines, I started getting the following PHP error:
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 43 bytes) in /var/www/client/dir/libs/adodb/adodb.inc.php on line 3850
Which means that PHP has run out of the 8 megs of memory allocated to it and is dying a vociferous death.
The collective wisdom of the web writes that the only solutions are both to increase the memory_limit value in php.ini and, failing that, re-write your code to be more resource-friendly. Probably good advice on both accounts so I fired up nano and set memory_limit to 16M. And then when that failed I upped it to 32M. And which point I got a seg fault so I stopped moving in that direction. I set it back to 8M since the other two machines the app is running on were just fine with that.
Well what about the code angle? Though the error points to ADODB as the culprit I knew that was pretty unlikely; it’s a great library and no amount of googling turned up anything to even suggest there were memory issues with it so instead, to rule out inefficiency in my queries, I reduced a simple case down to the simplest query I could reasonably expect to work:
SELECT * FROM the_table LIMIT 1;
…and still got the error. LIMIT 0: error. I deleted all the rows from the table so that it could not return any memory-hogging data and… still the error.
What the hell?
How can PHP be running out of memory on a query that can’t possibly be, for all intents and purposes, using any memory? And why only on this one machine?
The machine in question is running Ubuntu, patched with all the latest updates. The day before this problem started some of those updates had been libapache2-mod-php5, php5 and php5-mysql - could the updates be the problem? Maybe there’s an incompatibility between ADODB and the newly-installed PHP after all?
Fortunately, having just moved to Vancouver, my home Ubuntu machine was still laying on the floor wrapped in bubble wrap and on it was the older, unpatched version of Ubuntu. I ripped it open, fired it up, ftp’d in, loaded up the application and… got the same damned error.
Well at least that rules out PHP versioning issues and still leaves ADODB off the hook.
What else had changed? Oh, right….
I looked at my application’s configuration file. In it there’s a flag to define whether or not the application is running in the development environment or in the live production environment. This flag controls such things as which MySQL username and password to use when connecting to the database and in fact the very name of the database to connect to (the smart developers among you will at this point be wondering: why not make life easy for yourself and use the same username and password for both databases? To you I say: yeah, yeah, shut it).
The Solution
The day before yesterday I’d made a small (minor, barely worthy of note) change to that config file. A wee change that didn’t affect the dev config but did affect the live config. I looked a bit closer. I’d made a mistake.
The net result of that mistake was that when switched to production mode the application ended up trying to execute MySQL queries using the username and password of the live site but against the database of the dev site. In other words, ADODB was trying to connect to a database that didn’t exist with a user that did exist. That is not a peanut butter/chocolate situation for PHP by any means.
I fixed that, fired it up again, and… success.
Moral of the story: if you’re going to query a database, make sure it actually exists. And when bug-hunting, start with the things you’ve done and work your way out from there 