Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

SOLVED: Admin unaccessible: Fatal error Memory exhausted

Go to End

19 Posts   3886 Views


Community Member, 30 Posts

26 July 2011 at 12:46am

When trying to access /admin I get a blank page. After enabling debug mode etc. I see an error message that says that Memory is exhausted (always in one of several files such as sapphire\core\model\SQLQuery.php). After increasing the memory step by step to 1 GB I suspect the problem is some severe memory leak. I can't really say what causes this. Only that it started after a Content Editor edited and moved pages around in the backend. Possibly he deleted the /home Page (because it was re-created on running /dev/build the first time after /admin had stopped working).

  • There are no weird entries in the database as far as I can tell (no comment spam etc.)

  • I can access other admin tabs such as /admin/assets without problem.

  • The frontend works without problems.

  • Silverstripe Version 2.4.5.

  • I could replicate the problem by copying files and DB to a local XAMPP installation.

Any suggestions?

P.S. Plenty of people seem to have had this problem over the last 2 years. Most of them seem to have had a very low memory_limit (fixed after increasing to 64 MB). Others had 20.000 spam comments. Some just got "fixed by itself" and most never got a reply.


Forum Moderator, 1899 Posts

26 July 2011 at 2:21am

Edited: 26/07/2011 2:36am

I had this recently for a client that when they uploaded an image - it went HUGE - 2 meg become 50meg. I assumed this had something to do with it and removed the image and things started to work again.


Community Member, 30 Posts

26 July 2011 at 2:27am

Edited: 26/07/2011 2:29am

I just checked and I don't see any image or file that I didn't upload myself weeks ago.

Anyway, even if that were the problem "deleting the image" is certainly no fix! This looks like a serious bug doesn't it?


Forum Moderator, 1899 Posts

26 July 2011 at 2:39am

That bug was annoying, but the site was an old one of mine, and in anycase I put so much code on top that I often find it hard to point solely at the core code having serious bugs - they normally end up disappearing when tested on a clean install.

Do you have a stack trace?


Community Member, 30 Posts

26 July 2011 at 2:44am

What causes faults is usually stuff you wrote yourself, that is very true.

I don't have a stack trace because I'm just diving into the Silverstripe Core and I'm a little lost :-(. If you tell me what to do I'll gladly oblige :-).


Forum Moderator, 1899 Posts

26 July 2011 at 2:50am

find where it breaks and then work back a little to find a nice place to put...


if you have it reproduced locally then using a debugg will probably help find the right place for the above statements...


Forum Moderator, 5523 Posts

26 July 2011 at 11:32pm

omarkohl you may also want to look into installing XDebug or XHProf and doing some serious profiling to see what's hogging things! Is it just 1 request or over time?

DataObject does have a known memory leak which is why you'll see threads recommending against using large DataObjectSets but that will be solved for 3.0.


Community Member, 30 Posts

27 July 2011 at 2:36am

Edited: 27/07/2011 2:37am

We found the error!!

You should definitely try this for yourself (I tried on several Silverstripe Installs and it works every time).

If you have page A with child page B. Then move page B to the root and move page A to be child of B. You may save both pages (though it doesn't matter if you do) but you may NOT PUBLISH them. Try reloading the Backend and enjoy.

Root--A--B (original)

Second possibility: Again exchange both pages and this time save and publish A (the child page). Same result.

Only if you save and publish B (the parent) it works.

The reason for this is of course a circular reference. But in the first scenario there is no real circular reference (you can't see it in the DB). It has something to do with the fact that the Sitetree and Sitetree_Live tables have differing information on who is who's parent. In the second scenario you get a true circular reference in the Sitetree_live table.

SiteTree::batch_permission_check() is a recursive function that gets called for every child page (in this case infinite loop of children) until memory runs out.

Go to Top