V8 fatal CHECK failure with Unicode-escaped direct eval followed by function expression

[B0tton]

Version

v24.14.1

Platform

Microsoft Windows NT 10.0.22000.0 x64

Subsystem

v8

What steps will reproduce the bug?

Create demo.js:

function test() {
    \u0065\u0076\u0061\u006c() || (function() {})
}
test();

Run:

node demo.js

The process aborts with a V8 fatal CHECK failure.

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

It reproduces consistently on my machine with Node.js v24.14.1 on Windows.

The minimal reproduction seems to require both of the following:

1. eval is written using Unicode escapes: \u0065\u0076\u0061\u006c
2. A following function expression / function literal exists, such as (function() {})

This variant does not crash:

function test() {
    eval() || (function() {})
}
test();

This variant also does not crash:

function test() {
    \u0065\u0076\u0061\u006c() || 1
}
test();

So the crash appears to be related to Unicode-escaped direct eval combined with a following function literal.

What is the expected behavior? Why is that the expected behavior?

The script should execute normally without crashing.

The identifier \u0065\u0076\u0061\u006c is equivalent to eval, so this should behave like:

function test() {
    eval() || (function() {})
}
test();

That code executes normally and should not cause a fatal V8 abort.

What do you see instead?

Node.js aborts with a V8 fatal CHECK failure:

#
# Fatal error in , line 0
# Check failed: function_literal_id < script->infos()->length().
#
#
#
#FailureMessage Object: 0000008CDEDFDAC0
----- Native stack trace -----

 1: 00007FF655CD0ECD node::MultiIsolatePlatform::DisposeIsolate+5341
 2: 00007FF657133C4F V8_Fatal+287
 3: 00007FF6564D9B5F v8::RegExp::GetFlags+40191
 4: 00007FF656939641 X509_STORE_set_get_issuer+198369
 5: 00007FF6566B4755 v8::Promise::MarkAsSilent+559029
 6: 00007FF6566B4446 v8::Promise::MarkAsSilent+558246
 7: 00007FF6566AD62F v8::Promise::MarkAsSilent+530063
 8: 00007FF6566AD4A2 v8::Promise::MarkAsSilent+529666
 9: 00007FF656949E9C X509_STORE_set_get_issuer+266044
10: 00007FF656941931 X509_STORE_set_get_issuer+231889
11: 00007FF6569410DD X509_STORE_set_get_issuer+229757
12: 00007FF656941B7C X509_STORE_set_get_issuer+232476
13: 00007FF6563C417B v8::String::Utf8Value::~Utf8Value+173003
14: 0000020037E775FA

Additional version information:

node -v
v24.14.1

Additional information

No response

[DivyanshuX9]

I tested this on Node v22.x and the crash does not occur. This suggests a regression in newer V8 integration. Also reproduced on Windows only (not Linux).
But this could be a V8 bug so, we should check out V8 repo

[Renegade334]

Is there really a real-world usage case that's hit by this? It fell under Chromium's security model but doesn't fall under ours (since code is trusted), so the only rationale to backport v8/v8@9a884b1 would be if developers are genuinely adversely impacted by not being able to use this pattern.

[DivyanshuX9]

I think the main concern here is less about how common the pattern is, and more about the fact that this leads to a hard crash in Node.js.

Even if Unicode-escaped identifiers are uncommon in handwritten code, they can still appear in generated or obfuscated JavaScript. Since eval is a special form, this edge case might surface unintentionally.

Also, this appears to be a regression (it doesn’t reproduce on v22), which makes it a bit more concerning.

In general, Node shouldn’t abort on valid JavaScript input, even if the pattern is rare.

[Renegade334]

It's a preprocessor bug that was fixed upstream. There are inevitably hundreds of bugfixes that land in between the versions of V8 used in Node.js branches; there's no need to backport every single one, unless something is causing active problems, which this is highly unlikely to.

As above, if there are any real-world problems relating to this, then please point them out.