22415 Posts in 6944 Topics by 2750 members
General questions about getting started with SilverStripe that don't fit in any of the categories above.
|Go to End||Next >|
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.
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.
26 July 2011 at 2:21am Last edited: 26 July 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.
26 July 2011 at 2:27am Last edited: 26 July 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?
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?
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 .
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...
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.
27 July 2011 at 2:36am Last edited: 27 July 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.
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||Next >|