Massive Memory Leak in 4.5.8+ / 4.6
This Bug is caused by the fix for #15984
... due to patched tslib_fe::checkPageGroupAccess used by tslib_cObj::getTreeList
When a treelist is built by tslib_cObj::getTreeList, the access rights are checked using tslib_fe::checkPageGroupAccess.
Due to the Patch #15984 the rootline is now loaded for EVERY PAGE IN THIS TREELIST, just to check the rights of the parent pages.
It seems the PHP Garbage collection fails in this case causing a memory limit exception.
The implementation of t3lib_pageSelect::getRootLine itself seems to be alright.
An example (limited test case):
Creating a full treelist of 537 pages in 4 levels (1+14+138+384 pages) resulted in over 10330 calls of t3lib_DB::execSelectQuery and 10330 t3lib_DB::sql_fetch_assoc just for t3lib_pageSelect::getRootLine. The memory limit had to be raised to 1GB or the call failed with an exception.
This case was experienced in multiple PHP 5.3 environments.
xhprof PHP-Profiler including compared callgraphs are available.
Two solution(s) are also on their way, but are still work in progress.
Please contact us for further details ...
Updated by Ronny Vorpahl about 10 years ago
- File patch_32756.diff patch_32756.diff added
- File xhprof_PHP-Profiler_getTreeList_4.5.7.htm xhprof_PHP-Profiler_getTreeList_4.5.7.htm added
- File xhprof_PHP-Profiler_getTreeList_4.5.9.htm xhprof_PHP-Profiler_getTreeList_4.5.9.htm added
Some further Details:
The correct call order is:
- t3lib_DB::execSelectQuery + t3lib_DB::sql_fetch_assoc
The appended patch bypasses the getRootLine-functionality for getTreeList by using own functionality - it behaves now like 4.5.7.
The appended xhprof PHP-Profiler show the behavior of getTreeList using the unpatched Typo3-sources 4.5.7 and 4.5.9
Updated by Jigal van Hemert about 10 years ago
The implementation of getTreeList is a bit illogical: it gets the child elements recursively, so it goes from top to bottom. Yet for each element it checks the rootline for access properties (thus it goes back from bottom to top!).
If the recursion is removed the loop for the sublevels can check the access from its own data. Only the starting page needs to check the rootline for inherited properties.
Updated by Andreas Otto † almost 10 years ago
Helmut Hummel wrote:
#15984 introduced a performance nightmare. I would rather revert this "fix" until there is a solution which does not have such a huge impact.
Today 4.5.12 was released and the performance nightmare still exists.
What else than reverting #15984 can be done?
And please remember that 4.5 is a LTS release and should be a bit more stable than it currently is.