Last modified: 2011-01-25 00:37:05 UTC
I'm getting a Fatal Error when viewing Special:AllMessages: Fatal error: Allowed memory size of 52428800 bytes exhausted (tried to allocate 954416 bytes) in /home/yourwiki/htdocs/html/w/includes/specials/SpecialAllmessages.php on line 208 This should be fixed by adding pagination or something like that. This is reproducible if you have a lot of modified system messages.
Changed component to SpecialPages. Not an i18n issue.
(In reply to comment #0) > I'm getting a Fatal Error when viewing Special:AllMessages: > > Fatal error: Allowed memory size of 52428800 bytes exhausted (tried to allocate > 954416 bytes) in > /home/yourwiki/htdocs/html/w/includes/specials/SpecialAllmessages.php on line > 208 > > This should be fixed by adding pagination or something like that. This is > reproducible if you have a lot of modified system messages. > Does r45141 work for you?
no same error still happening (and yes I did svn up)
(In reply to comment #3) > no same error still happening (and yes I did svn up) > Try setting memory_limit = 80M in php.ini
AllMessages *seriously* needs to be paginated. It's way too big, not just from a memory usage standpoint.
Updated summary to reflect need for pagination.
Created attachment 5634 [details] Test patch against r45241 adding some debug lines checking mem usage Here's the memory_get_usage() results I get on my installation during various points of the rendering using this patch: memory 1: 13744240 near start of special page memory 2: 26570352 +13M after $wgMessageCache->loadAllMessages(); memory 3: 27037696 memory 4: 27037704 +0.5M after merging extensions, sorting to $sortedArray memory 5: 31358432 +4M after creating $messages memory 6: 33826000 +2.5M after rendering HTML output By far the biggest memory-user is just loading all the message texts to begin with, eating 13 megabytes. Yeowch! This is potentially hard to trim, as it could require changing the localization infrastructure. Building the array of sorted & transformed messages adds ~4 megabytes, and another ~2.5 megabytes gets used up making the HTML output. These could be reduced relatively easily by using a more compact rendering and/or doing some paging. (Your sizes will vary depending on system architecture, installed extensions, and what's in your localized messages.) If paging is done, we'll want a better integrated search, so it's still at least as easy as now to find a particular message based on name or content substring.
*** Bug 17800 has been marked as a duplicate of this bug. ***
*** Bug 15389 has been marked as a duplicate of this bug. ***
I think the problem is that with a rising number of extensions and personal changes the whole thing gets to big, I think the sugestion from Bug 15389 is a good beginning to solve this problem
I think there should be two things made 1. The messages should be grouped by extensions, so every extension and the mediawiki core messages should all get a single page 2. The messages should be paginated, maybe the way that there are only 50 or 100 messages per page I think this is a very critical point so there should be created a solution very soon
*** Bug 18439 has been marked as a duplicate of this bug. ***
*** Bug 18610 has been marked as a duplicate of this bug. ***
Created attachment 6086 [details] Paginate Special:Allmessages using TablePager, against r50159 I've been working on a complete solution to this and related bugs, using the TablePager class that is used in, for instance, CodeReview and the AbuseFilter. This framework provides a nice way to paginate large data sets such as Allmessages. Notable features include: *Server-side filtering by customisation state (modified, unmodified or all), and by prefix *Integrated language selection *No horizontal scrolling *No javascript :D The one aspect of the implementation that I'm not entirely happy with is the need to pretend, for the benefit of TablePager and its parent IndexPager, that the data was drawn entirely from the database. To do this, I had to write a FakeResultWrapper class that could be loaded with the message array and that would then spit out the results in the manner IndexPager expects from a real database. The alternative was to overload so many of IndexPager's core methods (extractResultInfo, getBody and formatRow, at least) as to rather defeat the object of using the framework in the first place. With the FakeResultWrapper, new features would have to be implemented to ResultWrapper itself, and utilised in TablePager, in order to cause breakages. The only breaking change is the removal of the variable output formats; only HTML is now supported. Both PHP and XML-formatted lists are now available through the API; this should certainly be the access point for scripts that need a machine-readable list of the messages. The PHP output was added almost exactly five years ago (r3454), from the time when message defaults were still specified in the database, XML 18 months ago (r27389). I'll CC both committers, but I think that this functionality should be accessed through the API. Admittedly there is currently no way to get the 'original' message through the API, but that's a separate bug. comments/criticisms would be much appreciated. The patch only blanks phase3/skins/common/allmessages.js for some reason; that file is actually now unused and can be deleted.
Applies cleanly and works well here. Have a strict standards bug though, on line 92 of the patched SpecialAllmessages.php: "Non-static method TablePager::getHiddenFields() should not be called statically, assuming $this from incompatible context"
Created attachment 6089 [details] Revised patch, still against r50159 Hmn, I guess this could be resolved by calling the method from the TablePager instance that's actually created? This revised patch should do this. I've also added some replacement CSS; this resolves bug7006.
Anyone planning on doing anything with this?
Glad something is going to be done soon, else it is the click of death (well, 5 minute freeze) for my browser (emacs-w3m), so I was going to say maybe make php the default output mode, instead of the giant HTML table). $ for i in php html xml; do echo -en $i:\\t GET -P ...title=Special:AllMessages\&ot=$i|Ac -c; done php: 164635 html: 1586231 xml: 209453
PHP was once the default mode, but was replaced with the human readable form because, well, it's not the human-readable form :-D It's a human-facing page, ergo it should have pretty human-readable content. For a machine-readable form, go to the API. Even with the limit set to 5000, so all the entries display, the TablePager version is still significantly more compact: I make it 1.31Mb vs 2.27Mb; not sure how that meshes with your stats, but it would be a significant saving even if it were only 200kB.
Done in r53286
I had asked for this in duplicate bug 15389, and I must say that it works fine now. Thank you.
