Closed Bug 1463371 Opened 7 years ago Closed 6 years ago

Crash [@ js::CompartmentChecker::fail] with setModuleResolveHook in different compartment

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla62
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox60 --- unaffected
firefox61 --- unaffected
firefox62 --- fixed

People

(Reporter: decoder, Assigned: jonco)

References

(Regression)

Details

(5 keywords, Whiteboard: [jsbugmon:update])

Crash Data

Attachments

(1 file)

The following testcase crashes on mozilla-central revision dc1868d255be (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --no-threads): var g = newGlobal(); g.eval(` setModuleResolveHook(function(module, specifier) {}); `); let m = parseModule(` import ns from './foo.js'; `); m.declarationInstantiation(); Backtrace: received signal SIGSEGV, Segmentation fault. 0x00000000005b00e8 in js::CompartmentChecker::fail (c2=<optimized out>, c1=<optimized out>) at js/src/vm/JSContext-inl.h:39 #0 0x00000000005b00e8 in js::CompartmentChecker::fail (c2=<optimized out>, c1=<optimized out>) at js/src/vm/JSContext-inl.h:39 #1 js::CompartmentChecker::check (c=<optimized out>, this=0x7fffffffc780) at js/src/vm/JSContext-inl.h:58 #2 js::CompartmentChecker::check (this=0x7fffffffc780, obj=<optimized out>) at js/src/vm/JSContext-inl.h:71 #3 0x0000000000a527f3 in js::CompartmentChecker::check<JSFunction*> (handle=..., this=0x7fffffffc780) at js/src/vm/JSContext-inl.h:82 #4 js::assertSameCompartment<JS::Handle<JSObject*>, JS::Handle<JSFunction*>, JS::HandleValueArray> (t3=..., t2=<synthetic pointer>, t1=<synthetic pointer>, cx=<optimized out>) at js/src/vm/JSContext-inl.h:235 #5 JS_CallFunction (cx=<optimized out>, cx@entry=0x7ffff5f17000, obj=obj@entry=..., fun=fun@entry=..., args=..., rval=..., rval@entry=...) at js/src/jsapi.cpp:2932 #6 0x000000000045ac54 in CallModuleResolveHook (cx=0x7ffff5f17000, module=..., specifier=...) at js/src/shell/js.cpp:4302 #7 0x0000000000c60a96 in intrinsic_HostResolveImportedModule (cx=<optimized out>, argc=<optimized out>, vp=<optimized out>) at js/src/vm/SelfHosting.cpp:2155 #8 0x00000000005b59be in js::CallJSNative (cx=0x7ffff5f17000, native=0xc60980 <intrinsic_HostResolveImportedModule(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/vm/JSContext-inl.h:280 [...] #22 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:9326 rax 0x0 0 rbx 0x7fffffffc780 140737488340864 rcx 0x7ffff6c282ad 140737333330605 rdx 0x0 0 rsi 0x7ffff6ef7770 140737336276848 rdi 0x7ffff6ef6540 140737336272192 rbp 0x7fffffffc720 140737488340768 rsp 0x7fffffffc700 140737488340736 r8 0x7ffff6ef7770 140737336276848 r9 0x7ffff7fe4780 140737354024832 r10 0x58 88 r11 0x7ffff6b9e7a0 140737332766624 r12 0x7fffffffc750 140737488340816 r13 0x7fffffffc890 140737488341136 r14 0x1277cf0 19365104 r15 0x7ffff5f07270 140737319563888 rip 0x5b00e8 <js::CompartmentChecker::check(JSObject*)+216> => 0x5b00e8 <js::CompartmentChecker::check(JSObject*)+216>: movl $0x0,0x0 0x5b00f3 <js::CompartmentChecker::check(JSObject*)+227>: ud2 This is very likely shell-only with setModuleResolveHook not expected to be used in a different compartment.
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/e862899dca3f user: Jon Coppeard date: Wed May 16 11:59:09 2018 +0100 summary: Bug 1461751 - Simplify module resolve hook to be a function pointer r=luke r=baku This iteration took 291.341 seconds to run.
My change in bug 1461751 had some unintended consequences for the shell. Previously, the module loader and module resolve hook were only installed for the main shell global. Modules could not be used on other globals. Bug 1461751 moved the resolve hook to be a property of the runtime rather than the global which resulted in there now being a module resolve hook for all shell globals. This doesn't work because the shell hook calls a JSFunction which now can be in a different compartment. This isn't a problem for the browser because the hook is not implemented in JS. The simplest thing to do is to make the shell work the way it did before by storing the JSFunction on the shell global in an application reserved slot.
Assignee: nobody → jcoppeard
Attachment #8980246 - Flags: review?(luke)
Attachment #8980246 - Flags: review?(luke) → review+
Pushed by jcoppeard@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/a33765bea383 Revert to previous behaviour for setting module resolve hook in the shell r=luke
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Regressed by: 1461751
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: