Last modified: 2010-05-15 15:42:53 UTC
I have a mediawiki site hosted by bluehost.com 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
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.
Searching the php bug database, maybe the behavior I am seeing is because of
http://bugs.php.net/bug.php?id=39445, which was fixed recently.
*** Bug 8238 has been marked as a duplicate of this bug. ***
*** Bug 8459 has been marked as a duplicate of this bug. ***
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. ;)
Well, I tried this and it still doesn´t work. Any other ideas?
*** Bug 8113 has been marked as a duplicate of this bug. ***