Last modified: 2014-02-24 18:44:40 UTC
The URL given above fails sometimes with out of memory error: [13/Mar/2011:10:37:06 +0000] "GET /w/i.php?title=Project:Translator&offset=20110227192534&limit=100 HTTP/1.1" 500 0[13/Mar/2011:10:37:18 +0000] "GET /w/i.php?title=Project:Translator&offset=20110227192534&limit=100 HTTP/1.1" 500 3183
Memory limit is set to 150M.
[13-Mar-2011 10:37:06] PHP Fatal error: Allowed memory size of 157286400 bytes exhausted (tried to allocate 793462 bytes) in /www/w/includes/OutputPage.php on line 1152 [13-Mar-2011 10:37:18] PHP Fatal error: Allowed memory size of 157286400 bytes exhausted (tried to allocate 849921 bytes) in /www/w/includes/SkinTemplate.php on line 1358
Not running out of memory now at 140M, but still very slow, can be 20s.
Slow, but renders. WORKSFORME?
(In reply to comment #4) > Slow, but renders. WORKSFORME? No, it's just that &limit is broken, so the URL can't be used to test.
Ugh. "Lowest" is now also being used for fatal errors? It seems all the interesting bugs are being concentrated in there. :)
I'm not a LQT maintainer, and I was just trying to apply the Bugzilla etiquette principle of "Bug status, priority, and target milestone fields summarize and reflect reality and do not cause it." The reality reflected in the history of this bug is that nobody has worked on a fix, and nobody seems to have a plan to work on it. If you have a better alternative for the priority field, go ahead. :)
(In reply to Quim Gil from comment #7) > The reality reflected in the history of this bug is that nobody has worked > on a fix The same can be said of all bugs in LQT. Or of all bugs in general.
(In reply to Nemo from comment #8) > The same can be said of all bugs in LQT. Or of all bugs in general. You left out the important part of the sentence: ", and nobody seems to have a plan to work on it." Which was my reason to set this to Lowest. Setting back to Normal because I don't want to argue with you, and anyway the LQT maintainers (if any) are the ones to decide. A conversation about the status and future of LQT bugs might be indeed needed, but this report is not the place for it.
(In reply to Quim Gil from comment #9) > (In reply to Nemo from comment #8) > > The same can be said of all bugs in LQT. Or of all bugs in general. > > You left out the important part of the sentence: ", and nobody seems to have > a plan to work on it." Which was my reason to set this to Lowest. > > Setting back to Normal because I don't want to argue with you, and anyway > the LQT maintainers (if any) are the ones to decide. A conversation about > the status and future of LQT bugs might be indeed needed, but this report is > not the place for it.
