Last modified: 2013-10-21 17:21:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T57818, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 55818 - enabling wgDebugFunctionEntry triggers infinite loop
enabling wgDebugFunctionEntry triggers infinite loop
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.22.0
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-16 22:34 UTC by Erik Bernhardson
Modified: 2013-10-21 17:21 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
stack trace produced by the bug (9.20 KB, application/octet-stream)
2013-10-16 22:34 UTC, Erik Bernhardson
Details

Description Erik Bernhardson 2013-10-16 22:34:06 UTC
Created attachment 13518 [details]
stack trace produced by the bug

When enabling profiling by providing a StartProfiler.php script along with setting 
    $wgDebugFunctionEntry = true;
php hits its maximum nesting level. The error stacktrace is attached.

In short, wfProfileIn calls wfDebug.  wfDebug calls wfRunHooks which(the impl not the hooks) goes back to calling wfProfileIn by the 16th stack frame.

The bug can be reproduced for bisecting by creating StartProfiler.php and executing 

$ echo "\$wgDebugFunctionEntry = true;wfProfileIn('test');" | php maintenance/eval.php 

This finds af125df5199b5c232bf335d735cecc6d8f8e9784 as the change which caused this bug.  Tested on a new mediawiki/vagrant instance with no additional extensions enabled.
Comment 1 Andre Klapper 2013-10-17 10:57:26 UTC
(In reply to comment #0)
> This finds af125df5199b5c232bf335d735cecc6d8f8e9784 as the change which
> caused this bug.

CC'ing author and reviewer.
Comment 2 Tyler Romeo 2013-10-17 21:32:08 UTC
For the record, here is the traceback:

0. wfRunHooks at GlobalFunctions.php:3885
1. Hooks::run at Hooks.php:136
2. wfProfileIn at Profiler.php:38
3. Profiler::profileIn at Profiler.php:207
4. Profiler::debug at Profiler.php:719
5. wfDebug at GlobalFunctions.php:934
6. wfRunHooks at GlobalFunctions.php:3885

This is all because of the undocumented Debug hook in wfDebug. The Debug hook is used if an extension wants to stop a debug message from being sent out (it cannot change the message because it's not sent by reference).

I really don't see the point of this hook, and ideally the wfDebug and related functions should be as low-level and avoid calling other code as much as possible to avoid situations like this. So I suggest just removing that hook, which would solve this loop.
Comment 3 Gerrit Notification Bot 2013-10-17 23:30:56 UTC
Change 90453 had a related patch set uploaded by EBernhardson:
Remove 'Debug' hook from wfDebug and wfDebugLog

https://gerrit.wikimedia.org/r/90453
Comment 4 Gerrit Notification Bot 2013-10-21 00:54:59 UTC
Change 90453 merged by jenkins-bot:
Remove 'Debug' hook from wfDebug and wfDebugLog

https://gerrit.wikimedia.org/r/90453
Comment 5 Kevin Israel (PleaseStand) 2013-10-21 04:38:53 UTC
(In reply to comment #2)
> This is all because of the undocumented Debug hook in wfDebug. The Debug hook
> is used if an extension wants to stop a debug message from being sent out (it
> cannot change the message because it's not sent by reference).
> 
> I really don't see the point of this hook, ...

It was added in r88843 (bug 29140) and in fact documented.
Comment 6 Erik Bernhardson 2013-10-21 17:21:30 UTC
bug 29140 does seem like a reasonable use case, but i wonder if it could be implemented such that it doesn't hook into each call to wfDebug.  I havn't fully investigated whats happening here in mw, but in libraries like Monolog they have the ability to build a list of messages and cache them in-process, to be flushed to an external source(like firebug) with a single call at the end of the request rather than every ->log() call.  I wonder if something similar could be appropriate for re-enabling firebug.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links