Fireboard plus Joomla: "Out of Memory" error.

June 28, 2008 11:48 AM

Joomla and Fireboard Memory Problem: Whenever I click on a post, Fireboard breaks and reports that it's out of memory. I've increased memory allocation with php.ini and .htaccess-- it's now at 64m-- and this has had no effect. I'm using Hostgator. Any suggestions on how to get Fireboard operating properly (or for that matter, a host which runs Fireboard easily)? Thanks.
posted by darth_tedious to computers & internet (7 comments total)

Can you copy/past the actual error it's throwing? is it really consuming 64M? Some googling suggests it should fit in a 12M process. 64M is actually pretty high (typically I've only seen that exceeded have been when huge queries get cached or you try to resize a rather large image with gd).

Are you on shared or dedicated hosting w/ hostgator?

I ask only because if you're on shared, I highly doubt that Hostgator is going to let you suck down 64M for a php process. They've probably got it capped somewhere.

if you're on dedicated, please note changes to php.ini typically do not take effect until you restart your webserver (not sure at what point htaccess changes would take effect -- presumedly on page load, though I would suspect that php.ini might cap that setting). bouncing it ain't going to hurt, since you're already hitting a fatal error.
posted by fishfucker at 12:29 PM on June 28

Thanks, FF. Error as follows:

***

Fatal error: Out of memory (allocated 55574528) (tried to allocate 1034449 bytes) in /public_html/center/components/com_fireboard/template/default/fb_pathway.php on line 67

***

It's shared hosting.

>I ask only because if you're on shared, I highly doubt that Hostgator is going to let you suck down 64M for a php process.

I asked them to increase it, and was told they were now boosting it to 64m. I then started dropping php.ini and .htaccess in various folders with 64m allocated.

>They've probably got it capped somewhere.

Possible; hope not.
posted by darth_tedious at 1:23 PM on June 28

Wow, that is an extraordinary amount of RAM for a process to take. I took a peek at the code and while I'm not familar with the joomla architecture at all, there is a rather unpleasant loop right where you are failing out. Now, it is possible that it's sucking down memory somewhere else and that loop just happens to break the camel's back, but the way that loop is written it's also quite possible it is what is killing your app.

Is this a fresh joomla install or an existing one? If existing, does it have a ton of categories or free tags? What that loop is doing (based on my 30 second analysis, so I could be wrong) is running through a set of parent ids for each category you have. If there's something weird with your cats (possibly some kind of circular ancestry where a child is parent of itself), you will get stuck in an infinite loop. If parent_id doesn't get set properly, you could get stuck in an infinite loop. If you have a crapload of categories you could get in a loop that is inordinately large and causes enough queries to be run that the server falls over. Basically, that loop (again, by my brief analysis) has about a million different ways that it could fail, but the three most likely ones are: large number of categories (possibly from free tagging?), no categories and the null situation is handled improperly, a category heirarchy that has a circular reference.

if it's a fresh install, it may be handling the null case improperly for some reason. Add a category if there aren't any.

one strategy you can try is making a backup of the file and then deleting that entire block from line 43 to line 73. If it renders fine without that loop, that was your problem, and you now have to figure out why that loop is getting stuck. If it fails somewhere else, you're running out of memory in multiple locations. You can also try to file a bug with the developers.
posted by fishfucker at 1:53 PM on June 28

btw, what ver are you using? I checked out 1.0.4 'stable', but it looks like they have several versions available.
posted by fishfucker at 1:56 PM on June 28

>If there's something weird with your cats (possibly some kind of circular ancestry where a child is parent of itself), you will get stuck in an infinite loop. If parent_id doesn't get set properly, you could get stuck in an infinite loop.

I think you've pegged it with this.

Basically, this was installed a couple of days ago, and I think I may have deleted the top category.

In fact, when I look into the categories, I'm shown this:

***

Notice: Unknown column '_FB_TOPLEVEL' in 'field list' in /public_html/center/includes/database.php on line 307

/public_html/center/includes/database.php:498
/public_html/center/administrator/components/com_fireboard/admin.fireboard.php:461
/public_html/center/administrator/components/com_fireboard/admin.fireboard.php:125
/public_html/center/administrator/index2.php:69

***


>if it's a fresh install, it may be handling the null case improperly for some reason. Add a category if there aren't any.

I've added a category-- but same result. What's the best way to spot/fix circular ancestry?

And thanks for your help... :)
posted by darth_tedious at 2:18 PM on June 28

Unknown column '_FB_TOPLEVEL' in 'field list' in /public_html/center/includes/database.php on line 307

yeah, that ... is weird .... um, ... hmm. you really shouldn't have a missing column -- even if you removed the topmost category it shouldn't kill any of the data structure (and even if that's a calculated field it should still show up as null).

can you roll back and do a reinstall? that might honestly be quickest. I'm not familiar enough with Joomla to be able to help you reconstruct what exactly went wrong -- realistically joomla or whatever should prevent you from ending up with orphan data, but the way that fireboard module was written gives me a pretty low confidence level in its ability to prevent you from screwing itself.

If it's a fresh install, I'd just start over in another directory with another database.

or alternately, you can search on that error and get some leads -- it looks like installing the 1.0.3 version isn't exactly straightforward (surprise, surprise). Here's something that looks promising:

Ok, forgot to publish the second "first level category".


It would have saved a lot of time if the docs had mentioned that one HAS to install the sample data first and then "first level categories" can be made by selecting "no parent" instead of "Top level category".

Why make things complicated ?

BJ.

posted by fishfucker at 3:39 PM on June 28

Thanks! Will take that approach...
posted by darth_tedious at 4:15 PM on June 28