Last modified: 2010-05-15 15:42:53 UTC
I am using MW 1.8.2 with PHP 5.2.0 and MYSQL 4.1.23 I have noticed a large number of bots and spiders visiting pages using the action=creativecommons ending. When they do it gives a 500 error and leaves a core dump file in my server directory of over 42megs in size. As you can imagine, my hosting service does not like this. I have read everything I can on the FAQ and bug reports here and have found no solution to my problem. I have tried setting the $wgEnableCreativeCommonsRdf to true and false and still get the same result. I tried using Brion's Metadata.php in SVN 18765 but that did not fix the problem. I still get the 500 error and a core dump. I have deactivated all my plugins and used a plain Jane LocalSettings.php and no change.
At this point your main hope is going to be to launch the debugger and see what's going on in there. :P You can start a single-process Apache daemon with 'httpd -X', this is generally easier to debug.
I wish I could be I am hosted, rather than hosting it myself. I can't seem to get their help in setting up xdebug and so I am at a loss as to what I can do at the present.
Ok...It seems that I have stumbled upon the cause of this problem. Bear with me as I explain this in great length so as to assist the next person. I started having problems with MW about 2 weeks ago. It seems that my hosting service did something to Zend Optimizer which MW did not like. After much searching I found that adding $wgDisableCounters = true; to my LocalSettings.php file fixed the 500 errors that I was getting. Almost that is. I found yesterday that when anyone called a page with the action=creativecommons and Special:UserRights that they got a 500 error and that it left a 42-44 meg core dump file in my directory. It seems that the fix for this is actually to comment out some sections of GlobalFunctions.php. The portion starts on line 2002 and ends on line 2010. Here it is: function wfGetCaller( $level = 2 ) {// /* $backtrace = debug_backtrace(); if ( isset( $backtrace[$level] ) ) { if ( isset( $backtrace[$level]['class'] ) ) { $caller = $backtrace[$level]['class'] . '::' . $backtrace[$level]['function']; } else { $caller = $backtrace[$level]['function']; } } else {*/ $caller = 'unknown'; //} return $caller; } Once I did this, all the 500 errors disappeared.
Aha! Now things start to come together. Looks like Zend Optimizer is the trigger/culprit for the debug_backtrace problems. Merging this to bug 8041.
*** This bug has been marked as a duplicate of 8041 ***
