Last modified: 2010-05-15 15:42:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8041 - wfGetCaller's call to debug_backtrace fails sometimes (apache 500 error)
wfGetCaller's call to debug_backtrace fails sometimes (apache 500 error)
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
PC Linux
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: 8113 8238 8459 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2006-11-26 05:19 UTC by Bubba
Modified: 2010-05-15 15:42 UTC (History)
3 users (show)

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


Description Bubba 2006-11-26 05:19:52 UTC
I have a mediawiki site hosted by and all of a sudden I started
getting apache 500 errors on a mediawiki site that was not modified.  bluehost
is using php 5.1.6 and apache 1.3.37 on linux 2.6.17-11_4.BHsmp, mysql
4.1.21-standard-log.  bluehost says they didn't change anything (php binary
itself has not changed).

Playing around with a separate installation on my bluehost site, I narrowed it
down to wfGetCaller in includes/GlobalFunctions.php.  In particular, the
debug_backtrace call can fail.  This is, I believe, a builtin C function for
php, but I'm not sure what else I can do at this point and maybe someone else
can get some more info in case this error starts becoming more widespread.

For now, I guess I can just have wfGetCaller return "unknown" and hence bypass
the call to debug_backtrace, but there's something more (and interesting) going
on here.

I'm sorry, but I don't have an explicit test case right now - if there's
something else I can spit out before the debug_backtrace call (which has no
arguments to report here) that might be useful let me know.
Comment 1 Bubba 2006-11-26 05:25:55 UTC
Searching the php bug database, maybe the behavior I am seeing is because of, which was fixed recently.

Comment 2 martinpre 2006-12-12 20:41:25 UTC
*** Bug 8238 has been marked as a duplicate of this bug. ***
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-02 23:49:58 UTC
*** Bug 8459 has been marked as a duplicate of this bug. ***
Comment 4 Brion Vibber 2007-01-02 23:53:03 UTC
Zend Optimizer turns out to be the trigger on this one.

I _think_ it's related to the use of stub objects and the funny object tricks
therein, but haven't found a minimal test case.

In r18774, debug_backtrace() is wrapped with a wfDebugBacktrace() function which
checks for the presence of this extension and returns an empty array if it's loaded.

Better, of course, would be Zend fixing their software. ;)
Comment 5 Pavel Kalinov 2007-01-06 21:40:08 UTC
Well, I tried this and it still doesn´t work. Any other ideas?
Comment 6 Brion Vibber 2007-03-06 21:41:25 UTC
*** Bug 8113 has been marked as a duplicate of this bug. ***

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