1592273 - Self-hosted JavaScript assertion info: [Latin 1]" js/src/builtin/Module.js:602: Required module should be in the stack iff it is currently being evaluated"

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P2)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 9b2ebbf56577 (build with --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --ion-offthread-compile=off):

var lfLogBuffer = `
  let c85 = parseModule("export * from 'a'; export * from 'b';");
  c85.declarationInstantiation();
  c85.evaluation();
`;
var lfModules = new Array();
setModuleResolveHook(function(module, specifier) {
    return lfModules.shift();
});
loadFile("");
loadFile("");
loadFile(lfLogBuffer);
function loadFile(lfVarx) {
    let lfMod = parseModule(lfVarx);
    lfModules.push(lfMod);
    lfMod.declarationInstantiation();
    lfMod.evaluation();
}

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  intrinsic_AssertionFailed (cx=cx@entry=0x7ffff5f27000, argc=<optimized out>, vp=<optimized out>) at js/src/vm/SelfHosting.cpp:469
#1  0x00005555559ca020 in CallJSNative (cx=0x7ffff5f27000, native=native@entry=0x555555d35230 <intrinsic_AssertionFailed(JSContext*, unsigned int, JS::Value*)>, reason=reason@entry=js::CallReason::Call, args=...) at js/src/vm/Interpreter.cpp:456
#2  0x00005555559bb32a in js::InternalCallOrConstruct (cx=<optimized out>, cx@entry=0x7ffff5f27000, args=..., construct=construct@entry=js::NO_CONSTRUCT, reason=reason@entry=js::CallReason::Call) at js/src/vm/Interpreter.cpp:548
#3  0x00005555559bb897 in InternalCall (cx=0x7ffff5f27000, args=..., reason=reason@entry=js::CallReason::Call) at js/src/vm/Interpreter.cpp:617
#4  0x00005555559bb9fc in js::CallFromStack (cx=<optimized out>, args=...) at js/src/vm/Interpreter.cpp:621
#5  0x000055555625bb43 in js::jit::DoCallFallback (cx=<optimized out>, frame=0x7fffffffaaa8, stub=0x7ffff4ddcf30, argc=1, vp=0x7fffffffaa38, res=...) at js/src/jit/BaselineIC.cpp:2940
#6  0x00003e04b78cf3e3 in ?? ()
[...]
#35 0x000017231647c040 in ?? ()
#36 0x0000555555cd802f in js::NativeObject::numDynamicSlots (this=<optimized out>) at js/src/vm/JSObject-inl.h:24
#37 js::NativeObject::slotInRange (this=0x3e04b78f00a8, slot=4107105208, sentinel=(js::NativeObject::SENTINEL_ALLOWED | unknown: 4126548520)) at js/src/vm/NativeObject.cpp:276
rax	0x555558088fa0	93825037537184
rbx	0x7fffffffa3d0	140737488331728
rcx	0x555556e32826	93825018308646
rdx	0x0	0
rsi	0x7ffff6eeb770	140737336227696
rdi	0x7ffff6eea540	140737336223040
rbp	0x7fffffffa410	140737488331792
rsp	0x7fffffffa3b0	140737488331696
r8	0x7ffff6eeb770	140737336227696
r9	0x7ffff7fe6cc0	140737354034368
r10	0x58	88
r11	0x7ffff6b927a0	140737332717472
r12	0x172316452c20	25439464926240
r13	0x7fffffffa680	140737488332416
r14	0x7ffff471d800	140737294489600
r15	0x7fffffffa458	140737488331864
rip	0x555555d3528c <intrinsic_AssertionFailed(JSContext*, unsigned int, JS::Value*)+92>
=> 0x555555d3528c <intrinsic_AssertionFailed(JSContext*, unsigned int, JS::Value*)+92>:	movl   $0x0,0x0
   0x555555d35297 <intrinsic_AssertionFailed(JSContext*, unsigned int, JS::Value*)+103>:	ud2

Comment 1

[Jon Coppeard (:jonco)]

I haven't looked into this in detail, but this is probably because the fuzzer sets the module resolve hook to a function that doesn't return the same module given the same parameters as required by the spec.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/2e4748827cda
user: Jon Coppeard
date: Wed Aug 09 18:05:15 2017 +0100
summary: Bug 1374239 - Store and re-throw module instantiation and evaluation errors r=shu

Probably related to bug 1374239.

Comment 3

[Jason Orendorff [:jorendorff]]

I guess the right answer, then, is either

• weaken the assertion to a runtime check; or
• leave the assertion, and add an extra runtime check only when the shell's setModuleResolveHook is used

Comment 4

[Andrei Purice]

Hey Christian,
Can you still reproduce this issue or should we close it?

Comment 5

[Christian Holler (:decoder)]

We no longer have setModuleResolveHook since the module loader refactoring, so marking as WFM.