Page MenuHomePhabricator

action=creativecommons give 500 error and core dump of 42 megs
Closed, ResolvedPublic


Author: patriarch

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

Version: 1.8.x
Severity: critical
OS: Linux
Platform: PC



Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 9:31 PM
bzimport set Reference to bz8459.
bzimport added a subscriber: Unknown Object (MLST).

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.

patriarch wrote:

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.

patriarch wrote:

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.

ayg wrote:

*** This bug has been marked as a duplicate of 8041 ***