Bug #28297
closed
Pagetree Filter - Crash when having many pages
Added by Florian Bachmann almost 13 years ago. Updated over 6 years ago.
100%
Description
We have a TYPO3-Site with 250.000 pages
Whenever we enter a short numeric id to the pagetree-filter-field (see attached screenshot) the TYPO3-Backend crashes with a bug-message:
Fatal error: Call to a member function offsetExists() on a non-object in t3lib\tree\pagetree\class.t3lib_tree_pagetree_dataprovider.php on line 180
To ensure this is a problem with the 4.5 Core we dumped only the pages table, and imported it to a completely fresh 4.5 Instance, only containing the initial DB-Tables and that pages-table.
In TYPO3 4.4 that has never been a problem
Files
| treebug.png (85.6 KB) treebug.png | Florian Bachmann, 2011-07-18 17:57 | ||
| treebug2.png (51.6 KB) treebug2.png | Florian Bachmann, 2011-07-18 19:22 | ||
| pages.sql_1_.zip (680 KB) pages.sql_1_.zip | Florian Bachmann, 2011-08-22 17:22 |
Updated by Tolleiv Nietsch almost 13 years ago
- Status changed from New to Needs Feedback
From what I see in the t3lib_tree_pagetree_DataProvider code is doesn't really do anything with the newly instantiated t3lib_tree_pagetree_NodeCollection object until it reaches this offsetExists(). Therefore it sounds very weird that this should be related to the 250k pages in your system.
Could you strip down the pages table to 1k pages and see if that issues goes away? In addition to that if think it would also be interesting to know what your PHP-Version is and whether you use APC or eAccelerator.
Updated by Florian Bachmann almost 13 years ago
- File treebug2.png treebug2.png added
When i reduce the table to 1000 Entries (DELETE FROM pages WHERE uid>1000) the function will work again (see screenshot)
It is running on my local WAMPP installation without any additional PHP plugins, but cURL
PHP Version 5.3.1
is doesn't really do anything with the newly instantiated t3lib_tree_pagetree_NodeCollection object until it reaches this offsetExists()
The (non)-object $reference, isn't just instanciated once before calling the function. it gets rewritten several times in a loop, at line 222
Updated by Tolleiv Nietsch almost 13 years ago
- Status changed from Needs Feedback to Accepted
- Complexity set to hard
Ok thanks - I think Georg or SteffenR might be able to possibly take care here
Updated by Florian Bachmann over 12 years ago
- File pages.sql_1_.zip pages.sql_1_.zip added
To make it easy to reproduce the problem, I created randomized a structural similar pagetree. And added a dump of the pages-table.
The Tree consists of zip-codes, with stores appended at a zip.
Entering short numbers makes the script crash. e.g. "80" will make it crash with the given PHP error message, "80798" works.
Maybe some other pagetree-bugs can be reproduced by this dump.
The crash happens on a completely fresh TYPO3 4.5 instance, with ONLY this pages-table (admin-user of course, too)
Updated by Andreas Wolf over 12 years ago
- Category changed from Backend User Interface to Pagetree
- Target version set to 4.6.0
Updated by Mr. Hudson over 12 years ago
Patch set 2 of change I6428f4827ed2c2f9fff6f58ed4081d6be035b3cf has been pushed to the review server.
It is available at http://review.typo3.org/5726
Updated by Mr. Hudson over 12 years ago
Patch set 2 of change I3734769a068e442359dc69d4262fd237f9384860 has been pushed to the review server.
It is available at http://review.typo3.org/5729
Updated by Patrick-Emil Zörner over 12 years ago
Fix for »Fatal error: Call to a member function offsetExists() on a non-object in xyz« in pagetree topPanel filter
I can confirm this Bug. The fix I made works for us. Please test it if it works for you.
Setup:
------
Typo3: 4.5.6 (fresh installation)
PHP: 5.2.13 (cgi) and PHP 5.3.5 (cgi-fcgi)
mysql: 5.1.39
Host: Domainfactory managed
Three domains/sites nearly 1300 pages
the exact reason is unknown to me but if you go to the pagetree topPanel filter as shown in the file and type a certain keyword (in this case discount; but also has also reported with other keywords) you get the following error message:
Fatal error: Call to a member function offsetExists() on a non-object in typo3_src-4.5.6/t3lib/tree/pagetree/class.t3lib_tree_pagetree_dataprovider.php on line 180
Also typo3 backend behaves really strange after this happens.
The attached patch fixes this behaviour. I am not sure though if it is just a workaround or if it ist is a valid fix. Maybe it is a
missbehaviour in t3lib_tree_pagetree_NodeCollection?! Anyway an assertion that $reference really is an object before you call offsetExists seems legit to me.
Updated by Steffen Ritter over 12 years ago
I dug into this very problem the last hours...
There are, two different problems: One about the $reference variable beeing not initialized anymore.
If this is fixed and the algorithm runs as expected you got another problem: memory and time limits.
If there are just put a '6' into it (as in the initial report) this would result in 18000 direct search hits, each having a rootline to be build.
Besides the technical problem with this a searchresult won't be useful.
Therefore we currently tend to additionally just do not present results if more than 500 hits are present (which is quite high anyhow)
Updated by Mr. Hudson over 12 years ago
- Status changed from Accepted to Under Review
Patch set 3 of change I3734769a068e442359dc69d4262fd237f9384860 has been pushed to the review server.
It is available at http://review.typo3.org/5729
Updated by Mr. Hudson over 12 years ago
Patch set 4 of change I3734769a068e442359dc69d4262fd237f9384860 has been pushed to the review server.
It is available at http://review.typo3.org/5729
Updated by Mr. Hudson over 12 years ago
Patch set 1 of change I8d05c34741ec40dfa15b414e206cde8495df73ec has been pushed to the review server.
It is available at http://review.typo3.org/6248
Updated by Xavier Perseguers over 12 years ago
- Target version changed from 4.6.0 to 4.5.8
- % Done changed from 0 to 80
Updated by Steffen Ritter over 12 years ago
- Status changed from Under Review to Resolved
- % Done changed from 80 to 100
Applied in changeset d7580828f176a6838f67c674ea764ea0fa56120e.
Updated by Riccardo De Contardi over 6 years ago
- Status changed from Resolved to Closed