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)
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)
(deleted),
patch
|
luke
:
review+
|
Details | Diff | Splinter Review |
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.
Updated•7 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Comment 1•7 years ago
|
||
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.
Assignee | ||
Comment 2•6 years ago
|
||
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)
Updated•6 years ago
|
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
Comment 4•6 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Updated•6 years ago
|
status-firefox60:
--- → unaffected
status-firefox61:
--- → unaffected
status-firefox-esr52:
--- → unaffected
status-firefox-esr60:
--- → unaffected
Flags: in-testsuite+
Updated•6 years ago
|
Keywords: regression
You need to log in
before you can comment on or make changes to this bug.
Description
•