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.
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.
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.
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.
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.
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.