Page MenuHomePhabricator

ExportTest failing on PHP 7.3.17 (so breaking Travis CI's run)
Closed, ResolvedPublic

Description

https://travis-ci.com/github/wikimedia/mediawiki/builds

Build output

There was 1 failure:

1) ExportTest::testPageByTitle
Failed asserting that two arrays are equal.

--- Expected
+++ Actual
@@ @@
 Array (
-    0 => 'Media'
-    1 => 'Special'
+    0 => ''
+    1 => ''
     2 => ''
-    3 => 'Talk'
-    4 => 'User'
-    5 => 'User_talk'
-    6 => 'Traviswiki'
-    7 => 'Traviswiki_talk'
-    8 => 'File'
-    9 => 'File_talk'
-    10 => 'MediaWiki'
-    11 => 'MediaWiki_talk'
-    12 => 'Template'
-    13 => 'Template_talk'
-    14 => 'Help'
-    15 => 'Help_talk'
-    16 => 'Category'
-    17 => 'Category_talk'
+    3 => ''
+    4 => ''
+    5 => ''
+    6 => ''
+    7 => ''
+    8 => ''
+    9 => ''
+    10 => ''
+    11 => ''
+    12 => ''
+    13 => ''
+    14 => ''
+    15 => ''
+    16 => ''
+    17 => ''
 )
/home/travis/build/wikimedia/mediawiki/tests/phpunit/includes/ExportTest.php:58
Logs generated by test case
=== 
[objectcache] [debug] MainWANObjectCache using store {class} {"class":"EmptyBagOStuff"}
[localisation] [debug] LocalisationCache using store LCStoreNull []
[localisation] [debug] LocalisationCache using store LCStoreNull []
[localisation] [debug] LocalisationCache using store LCStoreNull []
[MessageCache] [debug] MessageCache using store {class} {"class":"HashBagOStuff"}
[objectcache] [debug] MainWANObjectCache using store {class} {"class":"EmptyBagOStuff"}
[localisation] [debug] LocalisationCache using store LCStoreNull []
[MessageCache] [debug] MessageCache using store {class} {"class":"HashBagOStuff"}
[objectcache] [debug] MainWANObjectCache using store {class} {"class":"EmptyBagOStuff"}
[localisation] [debug] LocalisationCache::isExpired(en): cache missing, need to make one []
[objectcache] [debug] fetchOrRegenerate(global:NameTableSqlStore:slot_roles:traviswiki-unittest_): miss, new value computed []
[objectcache] [debug] fetchOrRegenerate(global:NameTableSqlStore:content_models:traviswiki-unittest_): miss, new value computed []
[MediaWiki\Content\ContentHandlerFactory::getContentHandler] [info] Registered handler for wikitext: WikitextContentHandler {"private":false}
[objectcache] [debug] fetchOrRegenerate(global:SqlBlobStore-blob:traviswiki-unittest_:tt%3A89): miss, new value computed []
===

Event Timeline

Krinkle renamed this task from MediaWiki core on PHP 7.3 failing on Travis CI to ExportTest failing on PHP 7.3 (Travis CI).Apr 30 2020, 8:43 PM
Krinkle added a project: MediaWiki-Parser.
Jdforrester-WMF renamed this task from ExportTest failing on PHP 7.3 (Travis CI) to ExportTest failing on Travis CI's PHP 7.3 run (but passing on Wikimedia's).Apr 30 2020, 8:48 PM

I created some travis-ci/* branches on GitHub pointing to the last good commit and those in between upto the first bad one.

The good news is, that the above listed commits as potential suspects, are no longer suspects.

The bad news is, the last good commit is now in fact also failing if re-run. I looked at other factors that changed in the base images of Travis CI in the first section of the build output, and the following emerges.

Before
$ php --version
PHP 7.3.16 (cli) (built: Mar 18 2020 13:08:58) ( ZTS )
Zend Engine v3.3.16, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.16, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.9.3, Copyright (c) 2002-2020, by Derick Rethans

$ composer --version
Composer version 1.10.5 2020-04-10 11:44:22
After
$ php --version
PHP 7.3.17 (cli) (built: Apr 16 2020 21:04:54) ( ZTS )
Zend Engine v3.3.17, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.17, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.9.4, Copyright (c) 2002-2020, by Derick Rethans

$ composer --version
Composer version 1.10.5 2020-04-10 11:44:22

So the difference is PHP 7.3.16 vs 7.3.17, and Xdebug v2.9.3 vs Xdebug v2.9.4.

https://www.php.net/ChangeLog-7.php#7.3.17
https://github.com/php/php-src/commits/PHP-7.3.17

@ArielGlenn Looks like this might be due to a bug in the XML processing. Something did change there upstream (see https://bugs.php.net/bug.php?id=61597 from ChangeLog), but I'm not very familiar with this. Could you take a look?

Argh, we're running 7.3.16-1+0~20200320.56+debian9~1.gbp370a75 on Wikimedia CI but the next time we touch it we'll bump to 7.3.17 I imagine. :-(

Jdforrester-WMF renamed this task from ExportTest failing on Travis CI's PHP 7.3 run (but passing on Wikimedia's) to ExportTest failing on PHP 7.3.17 (so breaking Travis CI's run).Apr 30 2020, 9:31 PM
Jdforrester-WMF triaged this task as High priority.

The code in question calls Language::getNamespaces() on the Language object for en and is getting an array where all the values are the empty string. The code in question from Language.php is:

	public function getNamespaces() {
		if ( $this->namespaceNames === null ) {
			global $wgMetaNamespace, $wgMetaNamespaceTalk, $wgExtraNamespaces;

			$validNamespaces = MediaWikiServices::getInstance()->getNamespaceInfo()->
				getCanonicalNamespaces();

			$this->namespaceNames = $wgExtraNamespaces +
				$this->localisationCache->getItem( $this->mCode, 'namespaceNames' );
			$this->namespaceNames += $validNamespaces;

			$this->namespaceNames[NS_PROJECT] = $wgMetaNamespace;
			if ( $wgMetaNamespaceTalk ) {
				$this->namespaceNames[NS_PROJECT_TALK] = $wgMetaNamespaceTalk;
			} else {
				$talk = $this->namespaceNames[NS_PROJECT_TALK];
				$this->namespaceNames[NS_PROJECT_TALK] =
					$this->fixVariableInNamespace( $talk );
			}

			# Sometimes a language will be localised but not actually exist on this wiki.
			foreach ( $this->namespaceNames as $key => $text ) {
				if ( !isset( $validNamespaces[$key] ) ) {
					unset( $this->namespaceNames[$key] );
				}
			}

			# The above mixing may leave namespaces out of canonical order.
			# Re-order by namespace ID number...
			ksort( $this->namespaceNames );

			Hooks::run( 'LanguageGetNamespaces', [ &$this->namespaceNames ] );
		}

I don't see any obvious way we could get through that code w/o at least setting $this->namespaceNames[NS_PROJECT] to a not-empty-string value. It's possible someone is calling Language::setNamespaces() with a bad parameter?

EDIT: nevermind, I switched the 'expected' and 'actual' values in my head. The expected values are fine. It's $xmlNamespaces which is bad.

It also fails for me locally with mediawiki-docker-dev and PHP 7.4.5, so whatever fix or breakage upstream made to simplexml naturally got into newer versions as well.

mediawiki:/var/www/mediawiki/tests/phpunit# php phpunit.php includes/ExportTest.php 
Using PHP 7.4.5
PHPUnit 8.5.4 by Sebastian Bergmann and contributors.
F.                                                                  2 / 2 (100%)
There was 1 failure:

1) ExportTest::testPageByTitle
…
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
-    0 => 'Media'
-    1 => 'Special'
+    0 => ''
+    1 => ''
     2 => ''
-    3 => 'Talk'
-    4 => 'User'
-    5 => 'User_talk'
-    6 => 'Project'
-    7 => 'Project_talk'
-    8 => 'File'
-    9 => 'File_talk'
-    10 => 'MediaWiki'
-    11 => 'MediaWiki_talk'
-    12 => 'Template'
-    13 => 'Template_talk'
-    14 => 'Help'
-    15 => 'Help_talk'
-    16 => 'Category'
-    17 => 'Category_talk'
-    18 => 'Gadget'
-    19 => 'Gadget_talk'
-    20 => 'Gadget_definition'
-    21 => 'Gadget_definition_talk'
+    3 => ''
+    4 => ''
+    5 => ''
+    6 => ''
+    7 => ''
+    8 => ''
+    9 => ''
+    10 => ''
+    11 => ''
+    12 => ''
+    13 => ''
+    14 => ''
+    15 => ''
+    16 => ''
+    17 => ''
+    18 => ''
+    19 => ''
+    20 => ''
+    21 => ''
 )

/var/www/mediawiki/tests/phpunit/includes/ExportTest.php:59

Isolated test case at:

https://3v4l.org/HtN9R

Shows the issue very clearly.

Change 593624 had a related patch set uploaded (by C. Scott Ananian; owner: C. Scott Ananian):
[mediawiki/core@master] Work around change in SimpleXMLElement behavior introduced in PHP 7.3.17

https://gerrit.wikimedia.org/r/593624

^ Please test the above patch. I've only tested on PHP 7.3.14 locally, but I'm using a codepath in simplexml (explicitly iterating over the SimpleXMLElement::children()) which returns a SimpleXMLElement in all cases, so should be unaffected by the "bug fix" upstream.

Change 593624 merged by jenkins-bot:
[mediawiki/core@master] Work around change in SimpleXMLElement behavior introduced in PHP 7.3.17

https://gerrit.wikimedia.org/r/593624

Change 593636 had a related patch set uploaded (by Reedy; owner: C. Scott Ananian):
[mediawiki/core@REL1_34] Work around change in SimpleXMLElement behavior introduced in PHP 7.3.17

https://gerrit.wikimedia.org/r/593636

Change 593637 had a related patch set uploaded (by Reedy; owner: C. Scott Ananian):
[mediawiki/core@REL1_33] Work around change in SimpleXMLElement behavior introduced in PHP 7.3.17

https://gerrit.wikimedia.org/r/593637

Change 593638 had a related patch set uploaded (by Reedy; owner: C. Scott Ananian):
[mediawiki/core@REL1_31] Work around change in SimpleXMLElement behavior introduced in PHP 7.3.17

https://gerrit.wikimedia.org/r/593638

Change 593638 merged by jenkins-bot:
[mediawiki/core@REL1_31] Work around change in SimpleXMLElement behavior introduced in PHP 7.3.17

https://gerrit.wikimedia.org/r/593638

Change 593636 merged by jenkins-bot:
[mediawiki/core@REL1_34] Work around change in SimpleXMLElement behavior introduced in PHP 7.3.17

https://gerrit.wikimedia.org/r/593636

Change 593637 merged by jenkins-bot:
[mediawiki/core@REL1_33] Work around change in SimpleXMLElement behavior introduced in PHP 7.3.17

https://gerrit.wikimedia.org/r/593637

Krinkle assigned this task to cscott.

Thanks!