Updated: Comment #N
Ive seen it twice in Drupal\locale\Tests\LocaleUpdateTest now, but also many other tests.
This is the same as #2216701: Random test failure in ToolbarAdminMenuTest.
Either a segfault or a fatal error out of 256mb (tried to get 512mb) memory in Connection.php::336. That's where it prepares the query, looks like something is trying to put something very unhealthy into a query?
For debugging, a test patch like over there, loop over arguments above that call, try to find non-scalar query arguments, output name, type and backtrace for them...
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | testbot-tell-us-your-secret-2223459-2.patch | 980 bytes | berdir |
| #2 | testbot-tell-us-your-secret-2223459-2.patch | 980 bytes | berdir |
| #2 | testbot-tell-us-your-secret-2223459-2.patch | 980 bytes | berdir |
| #2 | testbot-tell-us-your-secret-2223459-2.patch | 980 bytes | berdir |
| #2 | testbot-tell-us-your-secret-2223459-2.patch | 980 bytes | berdir |
Comments
Comment #1
berdirAnother one in https://qa.drupal.org/pifr/test/751008, same test.
Testbots: #813, #978.
Comment #2
berdirAh $query is just a string.. that makes this even weirder then.
Comment #3
berdirComment #5
berdirhttps://drupal.org/node/2223361 failed again with NodeTranslationUiTest on #953.
Of the above, #813 completely failed, the others were green. (#983, #978, #1883, #1733).
Going to re-test them all once more.
Comment #6
berdirAll green from #1823, #1883, #953, #1733, #978.
One more round...
Comment #8
berdirOk, https://qa.drupal.org/pifr/test/751133 also failed on LocaleUpdateTest, again #813, and the patch above also failed *again* on #813 and seems to be working on the others.
Looks like it's mostly that bot, I've disabled that one for now. Looks like #813 is failing pretty much every time on that test.
Comment #9
sunAdjusting issue title to include search keywords.
Hm. I just got the same or similar segfault on #953
Interestingly, all of these tests appear to be related to language/locale/*translation...?
I'd expect a segfault to yield some more verbose error message and backtrace in PHP's error log, no?
In the past year or so, I never actually saw the log output for a fatal error in the test review log. — Did we break the fatal error logging (or parsing) of run-tests.sh at some point?
#1808220: Remove run-tests.sh dependency on existing/installed parent site removed Drupal's error/exception handlers from the CLI script already, and additionally ensured to
ini_set('display_errors', TRUE)... — did we perhaps miss something, (1) either in the logging setup, (2) or in the error log parsing code?Comment #10
berdirNo, there is no additional output for a segfault. We'd have to enable core dumps and then look at them with gdb to get to the error. Maybe we can manually do that on #813? @beejebus said that he will look into this in Szeged next week, so #813 should be a bot that he can play with. Looks like this always happens on that bot.
Fatal errors do work, out of memory errors are fatals and they are displayed: https://qa.drupal.org/pifr/test/745658 is a nice example with a mix of Segfaults and out of memory fatals (the weird ones).
Comment #11
longwave#953 also failed for me 13 hours ago on Drupal\node\Tests\NodeTranslationUITest in #2115391: Numbers are displayed in search results list
Comment #12
sunCreated a separate issue for #2226351: Segmentation fault in Drupal\image\Tests\ImageStylesPathAndUrlTest, since those random failures only started to occur in the past 24-48 hours.
Comment #13
catchThis has disappeared as strangely as it appeared. Closing for now.