Problem/Motivation
https://www.drupal.org/project/drupal/issues/2829040#comment-14408271
A new one for me:
https://www.drupal.org/pift-ci-job/2316870
Entity.Drupal\KernelTests\Core\Entity\EntityAutocompleteTest
✗
Drupal\KernelTests\Core\Entity\EntityAutocompleteTest
fail: [Other] Line 0 of sites/default/files/simpletest/phpunit-319.xml:
PHPUnit Test failed to complete; Error: PHPUnit 9.5.11 by Sebastian Bergmann and contributors.Testing Drupal\KernelTests\Core\Entity\EntityAutocompleteTest
.. 2 / 2 (100%)Time: 00:02.829, Memory: 4.00 MB
OK (2 tests, 14 assertions)
Unsilenced deprecation notices (2)
2x: mb_strtolower(): Passing null to parameter #1 ($string) of type string is deprecated
2x in EntityAutocompleteTest::testSelectionSettingsHandling from Drupal\KernelTests\Core\EntitySeen here: #3263391: Remove deprecated code from book.module
Steps to reproduce
This seems probably pretty hard to replicate.
Proposed resolution
This actually seems benign and caused by our maybe inadvertent fuzzing since we don't care about the tag value in the first part of the test. The problem would seem to be the interaction of the following code some how.
EntityAutocompleteTest::testSelectionSettingsHandling
$request->query->set('q', $this->randomString());
EntityAutocompleteController::handleAutocomplete
if ($input = $request->query->get('q')) {
$typed_string = Tags::explode($input);
$typed_string = mb_strtolower(array_pop($typed_string));
array_pop is allowed to return null "If array is empty (or is not an array), null will be returned." Which means, if you give a sufficiently complicated string to the regex in Tags::explode so as to cause it to not match, $typed_string is empty, array_pop return null, and mb_strtolower() complains.
Remaining tasks
Work around an empty explode.
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 3264050-4.patch | 3.56 KB | neclimdul |
| #4 | 3264050-4.FAIL_.patch | 778 bytes | neclimdul |
| #2 | 3264050-2.patch | 2.8 KB | neclimdul |
| #2 | 3264050-2.changes.txt | 1.19 KB | neclimdul |
Comments
Comment #2
neclimdulExample:
https://3v4l.org/nEK5c#v8.1.2
Good news, this is exactly the sort of thing phpstan can hopefully help us sort out.
https://phpstan.org/r/4271c63e-ec45-491a-9da5-62cdc2e05edc
Attached is a patch, changes.txt is a diff -w so you can see what's actually changed since its mostly indenting. I bypassed all the match handing so the code would treat the invalid input the same as if the input was empty maybe saving a bit of work if this was ever actually triggered by something fuzzing a real site.
Comment #3
andypostIt may need a test but it's a real fix
Comment #4
neclimdulYou're probably right. Wrote a quick script that fuzzed the tag method until it got an empty array and here's a test. Failure patch is the interdiff.
Comment #5
neclimdulRunning the script a couple times, the problem seems to be anything that starts with a double quote?
Also the failed assertion is weird. Seems in the real world the effect is to get the entire list instead of just a filtered value? Probably an actual really good fix then, because that seems really unexpected and unwanted.
Comment #7
spokjeFAIL patch gonna fail...
Started a retest of the patch with the actual fix, which should mean that patch is now retested every 2 days.
Comment #10
catchNice to have a random failure that's an actual random failure instead of a false positive for a change.
Committed/pushed to 10.0.x and cherry-picked to 9.4.x/9.3.x, thanks!