After returning from Austin, I reconfigured rebuilt our OSUOSL testbots in order to improve their testing performance. However, I was unable to get any of the new builds to cleanly pass a D8 HEAD test, despite using the exact same build process as used for the AWS bots which are currently passing.
After investigating, the only difference between the working AWS builds and broken OSU builds is the PHP version. The AWS builds are using PHP 5.4.28-dotdeb, while the OSU builds are using a newer 5.4.29-dotdeb version. I updated one of the AWS builds to use 5.4.29-dotdeb, and it immediately failed the next two consecutive test runs.
Here are a few of the test runs which have thrown errors:
Updated AWS bot: https://qa.drupal.org/pifr/test/798643
Rebuilt OSU Bot: https://qa.drupal.org/pifr/test/798468
Rebuild OSU Bot: https://qa.drupal.org/pifr/test/798448
I'm seeing inconsistent error counts, and it's different tests each time ... so this appears to be an intermittent issue. Most of the errors look something like this:
Drupal\comment\Tests\CommentStatisticsUnitTest::testRead Erroneous data format for unserializing 'Mock_FakeStatement_25aa8a52' /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/comment/tests/src/CommentStatisticsUnitTest.php:62
Drupal\book\Tests\BookManagerTest::testGetBookParents with data set #2 (array(11, 12), array(11, 2, 10, 11), array(3, 10, 11, 12, 0, 0, 0, 0, 0, 0)) Erroneous data format for unserializing 'Mock_Connection_5ac09061' /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/book/tests/src/BookManagerTest.php:75
Drupal\Tests\Core\Entity\ContentEntityDatabaseStorageTest::testGetTableMappingRevisionable with data set #1 (array('test_id', 'test_bundle', NULL)) Erroneous data format for unserializing 'Mock_Connection_64e8cbdd' /var/lib/drupaltestbot/sites/default/files/checkout/core/tests/Drupal/Tests/Core/Entity/ContentEntityDatabaseStorageTest.php:1049 /var/lib/drupaltestbot/sites/default/files/checkout/core/tests/Drupal/Tests/Core/Entity/ContentEntityDatabaseStorageTest.php:452
Comment | File | Size | Author |
---|---|---|---|
#8 | 7-8-interdiff.txt | 2.82 KB | alexpott |
#8 | 2287139.8.patch | 62.86 KB | alexpott |
#7 | 2287139.7.patch | 59.95 KB | alexpott |
Comments
Comment #1
jthorson CreditAttribution: jthorson commentedComment #2
tim.plunkettDoctrine had the same problem, their fix is interesting.
https://github.com/doctrine/doctrine2/pull/1045/files
Comment #3
Fabianx CreditAttribution: Fabianx commentedThis breaks, because serialization format now is:
O - for normal objects
C - for objects implementing Serialize interface
But correct the right way to create a dynamic object without calling the constructor is using a ReflectionClass.
As Drupal relies on PHP 5.4, we can always use:
However it might be that the majority of that calls come from PHPUnit, symfony and doctrine. At least a quick search for 'unserialize' did not find much in core itself.
Comment #4
tim.plunkettThe first example in the OP is Drupal\Core\Database\Driver\fake\FakeStatement, the other three are Drupal\Core\Database\Connection.
But all of them are
That's not magic or special really...
@jthorson, can you try 5.4.29 with the two commits from #2114823: Update PHPUnit to 4.x rolled back? (da85a66 and 81d8d75).
Comment #5
jthorson CreditAttribution: jthorson commentedThese were definitely appearing prior to the PHPUnit update.
Comment #6
Tyrael CreditAttribution: Tyrael commentedthere was a behavior change affecting the unserialization of crafted strings, which was used by some libraries (like doctrine and phpunit-mock-objects).
should be fixed (for now) with https://github.com/sebastianbergmann/phpunit-mock-objects/pull/176 but there are no phpunit release containing the fix yet.
you can read more about the reasoning of the original change at
https://bugs.php.net/bug.php?id=67072
http://www.serverphorums.com/read.php?7,927788
http://www.serverphorums.com/read.php?7,946926
http://www.serverphorums.com/read.php?7,959450
Comment #7
alexpottI've pinned phpunit-mock-objects to the commit that fixes this.
Comment #8
alexpottForget the changes to composer.json and composer.lock
Comment #10
jthorson CreditAttribution: jthorson commented#8 passed the first test run against 5.4.29. Kicking off a second time, just to verify (as the pattern did seem intermittent, even though it was readily repeatable).
Ignore #9, that was due to a manual cancellation when the wrong bot picked up the test.
Comment #11
jthorson CreditAttribution: jthorson commentedTwo passes in a row. RTBC.
Comment #12
catchCommitted/pushed to 8.x, thanks!
Comment #15
Mile23Wondering if we can just bump this up to a straightforward version requirement here: #2375997: Avoid tying Drupal 8's composer.json to specific package commits.