Node: Flaky test sequential/test-http2-settings-flood

[addaleax]

• Version: master
• Platform: AIX p158a05 1 7 00CCB1C24C00
• Subsystem: v8?

The test in sequential/test-http2-settings-flood sometimes fails on AIX PPC64 with SIGILL and no other output (about 4/100 times). Bisecting points to @ronag’s cd6b00df3376d23643467b4c53e2e93bd9c28ce6, which obviously shouldn’t be causing that issue. It doesn’t reproduce when running the test with --jitless, so my best guess would be that it’s a V8 issue on PPC.

I can’t really debug this any further, the issue doesn’t seem to reproduce under gdb and core dumps don’t seem helpful, so it would be great if somebody in @nodejs/platform-aix (@miladfarca?) could take a look. In the short term, I guess we could also revert the commit above, although that’s obviously not ideal.

[miladfarca]

I have tested the above on AIX 6.1 as well as pLinux on a loop (~400 times) and it always passes.
Could you please add my key to the above machine:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQZihjEXcY52UZo09CEb29HwOWwXcmwbwZFR4rsACQQyGUexL4fkVrFfwuG8eV1vg5KECsO8LiGY/MHkNIpABaJJoip0Qxgv0pAFtAukIDjLXXOV/VNJjfIto16vOAehRZkmI+BtQP8TjoT2CSyJgvVQcay8BhH52in1LQQsyCi2crHLYzDrrCgY/rAmuVb1MzMnT8mFOdJ8E5RBhjnmc1K4YBKmNTf6yefgbOJssI0lLzp7Q2uytzp3pipg7AO/VqmRn8953UTJS/cOQeBi3nCYGpz4I7kOKHgwbdW1IP/XFfm0KO5daulHQeToRGIE85ntxF314wsYE3ZyeJwKgH

Edit:
Seems like https://github.com/nodejs/node/pull/31146 is causing it

[sam-github]

Gave access, permission already granted in https://github.com/nodejs/build/issues/1706

[addaleax]

Seems like #31146 is causing it

@miladfarca Can you figure out why it is crashing?

[miladfarca]

@addaleax Yes I will be looking into it, might be related to V8 deoptimization

[miladfarca]

This issue doesn't seem to be specific to PPC or AIX. It is also failing on x64-freebsd on the CI: https://ci.nodejs.org/job/node-test-commit-freebsd/nodes=freebsd11-x64/30698/console

I have done a debug compile on both pLinux and x64 Linux and this test periodically fails on the same DCHEK:

#
# Fatal error in ../deps/v8/src/deoptimizer/deoptimizer.cc, line 253
# Debug check failed: code == topmost_ implies safe_to_deopt_.
#
#
#
#FailureMessage Object: 0x7ffc4970cda0

There seems to be an issue with V8 de-optimizer.

[ronag]

@miladfarca: good job! would you mind creating a V8 ticket?

[miladfarca]

@ronag I've created this ticket but not sure if we need to reproduce it under V8 (and not nodejs), will wait for their reply:
https://bugs.chromium.org/p/v8/issues/detail?id=10101

[Trott]

@miladfarca Same results with a debug build on MacOS Mojave:

$ tools/test.py --mode=debug --repeat 1000 test/sequential/test-http2-ping-flood.js
=== debug test-http2-ping-flood ===                   
Path: sequential/test-http2-ping-flood
#
# Fatal error in ../deps/v8/src/deoptimizer/deoptimizer.cc, line 253
# Debug check failed: code == topmost_ implies safe_to_deopt_.
#
#
#

[miladfarca]

Thanks @Trott , just to confirm your mac is x64 correct? I'll add to the V8 ticket.

[Trott]

Thanks @Trott , just to confirm your mac is x64 correct? I'll add to the V8 ticket.

Yes, x64.

[ronag]

ping @nodejs/v8

[vtjnash]

It appears this is already known to be platform agnostic, but just for additional info, it also has been observed on debian9-docker-armv7 (https://ci.nodejs.org/job/node-test-commit-arm/28686/)

[mscdex]

FWIW this is also occurring in Ubuntu 18.04 containers.

[miladfarca]

@addaleax V8 ticket (https://bugs.chromium.org/p/v8/issues/detail?id=10101) is now closed with a comment suggesting an API misuse in node. Issue might be related to this commit/line which might need to be refactored: https://github.com/nodejs/node/commit/7e6104f1bb63a07885b08f277c3b708caa6b8a23#diff-9e96b9359319a317a5a1ee45f11eea67R126

[addaleax]

@miladfarca Thanks for the info, I’ll try to come up with a fix. They are right here, but I am surprised that ArrayBuffer::Detach() is unsafe for calling here.

Issue might be related to this commit/line which might need to be refactored: 7e6104f#diff-9e96b9359319a317a5a1ee45f11eea67R126

I’d like to avoid that, and instead try to not perform the invalid V8 call here.