Check failed: !holder_map.has_named_interceptor(). when running jest

[oliversalzburg]

Version

16.9.0

Platform

Linux oliver-home 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

vm

What steps will reproduce the bug?

#40030 (comment)

How often does it reproduce? Is there a required condition?

Every single time.

What is the expected behavior?

Tests run as usual.

What do you see instead?

#
# Fatal error in , line 0
# Check failed: !holder_map.has_named_interceptor().
#
#
#
#FailureMessage Object: 0x7ffe016dc1c0
 1: 0xb691f1  [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
 2: 0x1bf3094 V8_Fatal(char const*, ...) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
 3: 0x10ac4a1 v8::internal::ConcurrentLookupIterator::TryGetPropertyCell(v8::internal::Isolate*, v8::internal::LocalIsolate*, v8::internal::Handle<v8::internal::JSGlobalObject>, v8::internal::Handle<v8::internal::Name>) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
 4: 0x1c5aa55  [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
 5: 0x1c5b9eb v8::internal::compiler::JSGlobalObjectRef::GetPropertyCell(v8::internal::compiler::NameRef const&, v8::internal::compiler::SerializationPolicy) const [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
 6: 0x1e61ba3 v8::internal::compiler::JSNativeContextSpecialization::ReduceNamedAccess(v8::internal::compiler::Node*, v8::internal::compiler::Node*, v8::internal::compiler::NamedAccessFeedback const&, v8::internal::compiler::AccessMode, v8::internal::compiler::Node*) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
 7: 0x1e623c4 v8::internal::compiler::JSNativeContextSpecialization::ReducePropertyAccess(v8::internal::compiler::Node*, v8::internal::compiler::Node*, v8::base::Optional<v8::internal::compiler::NameRef>, v8::internal::compiler::Node*, v8::internal::compiler::FeedbackSource const&, v8::internal::compiler::AccessMode) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
 8: 0x1e6274e v8::internal::compiler::JSNativeContextSpecialization::ReduceJSLoadNamed(v8::internal::compiler::Node*) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
 9: 0x1df5e0a v8::internal::compiler::Reducer::Reduce(v8::internal::compiler::Node*, v8::internal::compiler::ObserveNodeManager*) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
10: 0x1c92604  [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
11: 0x1df60be v8::internal::compiler::GraphReducer::Reduce(v8::internal::compiler::Node*) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
12: 0x1df7895 v8::internal::compiler::GraphReducer::ReduceTop() [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
13: 0x1df7c48 v8::internal::compiler::GraphReducer::ReduceNode(v8::internal::compiler::Node*) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
14: 0x1ca03fd v8::internal::compiler::InliningPhase::Run(v8::internal::compiler::PipelineData*, v8::internal::Zone*) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
15: 0x1ca1291 v8::internal::compiler::PipelineImpl::CreateGraph() [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
16: 0x1ca1668 v8::internal::compiler::PipelineCompilationJob::PrepareJobImpl(v8::internal::Isolate*) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
17: 0xd94f5d v8::internal::OptimizedCompilationJob::PrepareJob(v8::internal::Isolate*) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
18: 0xd96358  [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
19: 0xd97e70 v8::internal::Compiler::CompileOptimized(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSFunction>, v8::internal::ConcurrencyMode, v8::internal::CodeKind) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
20: 0x11f4463 v8::internal::Runtime_CompileOptimized_Concurrent(int, unsigned long*, v8::internal::Isolate*) [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]
21: 0x15e67f9  [/home/oliver/.nvm/versions/node/v16.9.0/bin/node]

Additional information

#13804 sounds very related
16.8.0 didn't produce this result and still works as expected.

[richardlau]

Seen on the CITGM run for 16.9.0, https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2754
e.g. https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2754/nodes=ubuntu1804-64/testReport/junit/(root)/citgm/jest_v27_1_0/

[targos]

Seen on the CITGM run for 16.9.0, https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2754
e.g. https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2754/nodes=ubuntu1804-64/testReport/junit/(root)/citgm/jest_v27_1_0/

I'm sad I did not see that one, because I looked at the result for other machines and it was related to MongoDB process issues as usual...

Here's another run with the same failure against the master branch: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2756/nodes=ubuntu1804-64/testReport/junit/(root)/citgm/jest_v27_1_0/
So we can at least exclude the ABI compat patch (that's only in v16.9.0) from the possible causes.

/cc @nodejs/v8

[targos]

I think the failing check is from v8/v8@76b9d98

/cc @schuay

[akornatskyy]

The following can be used to reproduce this bug (in my case it crashes at 140):

describe('holder_map.has_named_interceptor crash', () => {
  for (let i = 0; i < 140; i++) {
    it(`${i}`, () => {
      //
    });
  }
});

Run test:

jest test.js

[targos]

The bug is triggered by the compilation of this function:

https://github.com/facebook/jest/blob/36208850c82313e48caa1adc1ef35f83f84f0c75/packages/jest-circus/src/state.ts#L48-L52

[targos]

Repro without Jest:

const vm = require('vm');

vm.runInNewContext(`

const STATE_SYM = Symbol('JEST_STATE_SYMBOL')
const eventHandlers = [() => {}];
const dispatch = async () => {
  for (const handler of eventHandlers) {
    await handler(this[STATE_SYM]);
  }
};

for (let i = 0; i < 1e6; i++) {
  dispatch();
}

`);

[targos]

I created an upstream bug: v8:12188
Cannot do more from my side.

[SimenB]

Is this caused by a v8 update? If so, any chance of reverting it? Or do we think (hope 😀) a fix will land upstream relatively quickly and it'll be cherry picked?

Seen on the CITGM run for 16.9.0, ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2754
e.g. ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2754/nodes=ubuntu1804-64/testReport/junit/(root)/citgm/jest_v27_1_0

I'm sad I did not see that one, because I looked at the result for other machines and it was related to MongoDB process issues as usual...

We should skip the mongo test if it causes noise hiding real issues. I'll open an issue in CITGM to track

EDIT: nodejs/citgm#875

[schuay]

Is this caused by a v8 update? If so, any chance of reverting it? Or do we think (hope ) a fix will land upstream relatively quickly and it'll be cherry picked?

I expect we'll fix this upstream in the next couple of days.

[targos]

@SimenB In the mean time, would you be open to tweaking the problematic function in jest-circus so that it doesn't trigger this bug (I can help with it)?
Edit: well, actually I can't find a way to prevent this optimization from happening 🙃

[SimenB]

Happy to land any change that would prevent it or just make it better in general and avoiding the problem altogether 🙂

[matinzd]

Jest tests are failing on Github actions also for the same reason like reproduction script after using jest.useFakeTimers() before each test case. Downgrading Nodejs ci version to 16.8 worked for me.

beforeEach(() => {
    jest.useFakeTimers()
})