| Minddragon | |
| Dec 3 2015, 7:59 PM |
| F3074742: info_array.txt | |
| Dec 13 2015, 1:17 AM |
| F3074614: T120267.log | |
| Dec 13 2015, 12:46 AM |
"PHP Fatal error: Unsupported operand types in /var/www/html/wiki/includes/registration/ExtensionRegistry.php on line 272"
It appears that this is the problem line in ExtensionsRegistry.php
$this->loaded += $info['credits'];
This error occurs on PHP 5.5 and PHP 5.6
It does not occur on PHP 5.4
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Work around APCu memory corruption bug | mediawiki/core | REL1_26 | +53 -2 | |
| Work around APCu memory corruption bug | mediawiki/core | master | +52 -2 |
Can you please indicate what extensions and skins you have installed and their versions? One of them likely has an invalid extension.json or skin.json file.
Steps to replicate:
Please note several other people on support forums are reporting similar conditions.
I managed to reproduce this with a virtual machine:
Then I found that a package "php56w" does not exist. I'm guessing you're using https://mirror.webtatic.com/yum/el6/latest.rpm as an additional repo? Let's try that.
After poking at it a bit, it looks like ExtensionRegistry decided to use APC for caching and the APC cache is somehow or other corrupting the keys in the stored arrays. Uninstalling php56w-pecl-apcu makes it work by not using APC. Probably this didn't happen in 1.25 because the code removed in https://gerrit.wikimedia.org/r/#/c/226441/ avoided the corruption by only storing strings in APC.
Can you stick a var_dump($data) right after ExtensionRegistry reads out of the APC cache at line 133?
It does appear to be corrupt somehow. Replacing $data = $this->cache->get( $key ); with $data = false; (and thus forcing the data to be computed rather than loaded from the cache) works.
Changing apc.serializer = 'default' to apc.serializer = 'php' in /etc/php.d/apcu.ini and then restarting httpd makes the problem go away.
It'd be great to have a minimal reproduction case (e.g. some cooked-up array that reliably triggers this corruption). Then, when APCBagOStuff is first initialized, try to set/get it, and if it is corrupt, default to the old behavior (serialize and deserialize in user code).
I'm pretty certain the bug is the one described here:
@Minddragon, you should edit /etc/php.d/apcu.ini and ensure apc.serializer is set to php rather than default.
Since this is a possible use-after-free in apcu's serialization code, I don't think that we should try to trigger it, as I suggested above. We should just fall back to the old behavior of serializing everything in PHP "user space" when APCu is used with the default serializer.
Change 258734 had a related patch set uploaded (by Ori.livneh):
Work around APCu memory corruption bug
Change 258930 had a related patch set uploaded (by Legoktm):
Work around APCu memory corruption bug
Fixed in master and backported to REL1_26. Will be included as part of the 1.26.1 release. Thanks everyone for investigating and fixing this :)