netocrat wrote:

You could also try:
$allPages = $pages[''];
foreach ($pages as $key => $val) {

		if ($key == '' && count($val) > 0) {
			$allPages = $val;
		}

}

/** Pages available to all */
wfSpecialSpecialpages_gen($allPages,'spheading',$sk);

I've been noticing this as an intermittent problem for a while now too. It's
occurring on two machines each running two separate MediaWiki versions; the
problem occurs under all configurations. Occasionally apache segfaults and the
page does not display at all.

Host1: PowerPC, PHP 5.1.4-pl4-gentoo and eAccelerator 0.9.5_beta2(?); MediaWiki
1.6.7 and 1.6.6.
Host2: Intel P4, PHP 5.1.2-gentoo and eAccelerator 0.9.5_beta2; MediaWiki 1.6.5
and 1.5.6.

Debug code shows that the $pages array returned by SpecialPage::getPages() when
printed with var_export() occasionally has an extra key=>element prepended,
which prints as e.g.

':ey' =>
array (
),

but that this key (most of the time) actually compares equal to ''. i.e. using
a foreach() loop will show two '' keys - that of this extra empty element and
that of the "real" non-empty array. This extra element is the one that's being
picked for $pages[''] - it's not that the real '' key doesn't exist, it's just
that the imposter occurs first.

Sometimes though, this extra element shows up in neither a var_export() nor a
foreach() iteration even when $pages[''] evaluates to an empty array.

Other information: when I added debug code for type-comparison, the imposter's
key compared type-equal - i.e. using an === comparison - with '' but NOT with null.

Some key strings other than ':ey' that I've seen so far: 'ðame', 'mey', 'Ley',
'!ey', ' ey', '/ey', 'Pey', 'rey'. For at least the '/ey' key string, the value
of $pages[''] was its "normal" non-empty array although I can't confirm whether
that key string compared equal to '' as I didn't have that debug code in place
at that point.

It seems likely that this is a problem of MediaWiki's only indirectly, and that
it's more directly a PHP or possibly an eAccelerator problem.

dewitt wrote:

I've been seeing the same problem, also with eAccelerator enabled. And thank
you, replacing the literal empty string '' with NULL did avoid the problem.

However, I believe the real bug may be this one in eAccelerator:

http://eaccelerator.net/ticket/63

That bug is apparently fixed in 0.9.5-rc1.

If you are stuck on an earlier version, one workaround proposed is to set the
following in eaccelerator.ini:

eaccelerator.shm_only = 1

robchur wrote:

Upstream bug fixed; closing.