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 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.
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. ***
