Repository navigation
V8 warnings crash process within DisallowJavascriptExecutionScope #63473
Description
Version
27.0.0-pre
Platform
*
Subsystem
No response
What steps will reproduce the bug?
For example, enter the reproduction from #24365 inside REPL with previews on, which evaluates the final expression via the inspector:
function AsmModule() {
'use asm';
function add(a, b) {
a = a | 0;
b = b | 0;
return a + b;
}
}
AsmModule();How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior? Why is that the expected behavior?
Either print the V8 warning, or do nothing.
What do you see instead?
#
# Fatal error in , line 0
# Invoke in DisallowJavascriptExecutionScope
#
#
#
#FailureMessage Object: 0x7ffd6a1b7cd0
----- Native stack trace -----
1: 0xa3daa1 [node]
2: 0x278ece1 V8_Fatal(char const*, ...) [node]
3: 0xdb70cd [node]
4: 0xdb6465 [node]
5: 0xc4d00b v8::Function::Call(v8::Isolate*, v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) [node]
6: 0xa4304c node::ProcessEmitWarningGeneric(node::Environment*, std::basic_string_view<char, std::char_traits<char> >, std::basic_string_view<char, std::char_traits<char> >, std::basic_string_view<char, std::char_traits<char> >) [node]
7: 0x998ee6 node::errors::PerIsolateMessageListener(v8::Local<v8::Message>, v8::Local<v8::Value>) [node]
8: 0xde02c0 [node]
9: 0x126f67e [node]
10: 0xccb062 [node]
11: 0xccc4ee [node]
12: 0xccce5b [node]
13: 0xd4dc95 [node]
14: 0x132d963 [node]
15: 0x1a46a76 [node]
Additional information
No response
Activity
DivyanshuX9 commentedon May 22, 2026
Lowkey quick fix in #63486 , it correctly identifies the root cause and stops the fatal crash. However, I think we can do better than a raw fprintf(stderr, ...) fallback, which loses Node's structured warning format, deprecation codes, and --redirect-warnings routing.
I'd like to propose a more robust approach:
Defer the warning instead of degrading it.
When PerIsolateMessageListener fires inside a DisallowJavascriptExecutionScope, rather than immediately falling back to raw stderr, we could enqueue the warning message and flush it via a libuv idle or check handle after the no-JS scope exits. This preserves:
The (node:PID) [DEP00XX] DeprecationWarning: format
--redirect-warnings file routing
Any other structured handling Node applies to warnings
Alternatively, if deferral is too complex, the guard should be moved to the top of PerIsolateMessageListener (not just before ProcessEmitWarningGeneric) to cover all message types like not just deprecation warnings since V8 can theoretically emit other message types in a no-JS scope too.
Either way, the fix also needs a regression test : something like a REPL test that feeds asm.js code with previews enabled and asserts: (a) no crash, and (b) the deprecation warning is still visible to the user in the expected format.
I'd like to take a shot at implementing this more complete fix if the approach sounds good to maintainers. Happy to discuss any changes to my PR.
DivyanshuX9 commentedon May 22, 2026
Senor @Renegade334 , need ya attention on my PR [https://github.com//pull/63491]
could you please review this fix? It addresses the crash when V8 emits warnings during REPL preview evaluation by deferring the warning emission until it's safe to call into JavaScript.
errors: handle V8 warnings in DisallowJavascriptExecutionScope
errors: handle V8 warnings in DisallowJavascriptExecutionScope
errors: handle V8 warnings in DisallowJavascriptExecutionScope
errors: handle V8 warnings in DisallowJavascriptExecutionScope
errors: handle V8 warnings in DisallowJavascriptExecutionScope
errors: handle V8 warnings in DisallowJavascriptExecutionScope
errors: handle V8 warnings in DisallowJavascriptExecutionScope