Closed
Bug 1284486
Opened 8 years ago
Closed 8 years ago
Crash [@ js::NativeObject::lookup] with ES6 Modules
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla50
Tracking | Status | |
---|---|---|
firefox50 | --- | fixed |
firefox51 | --- | unaffected |
People
(Reporter: decoder, Assigned: jonco)
References
Details
(Keywords: crash, regression, testcase, Whiteboard: [jsbugmon:update])
Crash Data
Attachments
(1 file)
(deleted),
patch
|
shu
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision c9a70b64f2fa (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug --enable-optimize, run with --fuzzing-safe):
let moduleRepo = {};
setModuleResolveHook(function(module, specifier) {
return moduleRepo[specifier];
});
try {
let b = moduleRepo['b'] = parseModule("export var b = 3; export var c = 4;");
let c = moduleRepo['c'] = parseModule("export * from 'a'; export * from 'b';");
c.declarationInstantiation();
} catch (exc) {}
let a = moduleRepo['a'] = parseModule("export var a = 1; export var b = 2;");
let d = moduleRepo['d'] = parseModule("import { a } from 'c'; a;");
d.declarationInstantiation();
Backtrace:
received signal SIGSEGV, Segmentation fault.
0x0000000000b06dfb in js::NativeObject::lookup (this=0x0, cx=cx@entry=0x7ffff6965000, id=...) at js/src/vm/NativeObject.cpp:233
#0 0x0000000000b06dfb in js::NativeObject::lookup (this=0x0, cx=cx@entry=0x7ffff6965000, id=...) at js/src/vm/NativeObject.cpp:233
#1 0x0000000000a31fb7 in js::IndirectBindingMap::putNew (this=0x7ffff69a61a0, cx=cx@entry=0x7ffff6965000, name=..., name@entry=..., environment=..., environment@entry=..., localName=..., localName@entry=...) at js/src/builtin/ModuleObject.cpp:239
#2 0x0000000000b45037 in js::ModuleEnvironmentObject::createImportBinding (this=0x7ffff7e733a0, cx=cx@entry=0x7ffff6965000, importName=..., importName@entry=..., module=..., module@entry=..., localName=..., localName@entry=...) at js/src/vm/ScopeObject.cpp:532
#3 0x0000000000b4f464 in intrinsic_CreateImportBinding (cx=cx@entry=0x7ffff6965000, argc=<optimized out>, vp=0x7ffff32ed178) at js/src/vm/SelfHosting.cpp:2155
#4 0x0000000000af01d4 in js::CallJSNative (cx=cx@entry=0x7ffff6965000, native=0xb4f2e0 <intrinsic_CreateImportBinding(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:232
[...]
#21 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:7437
rax 0x0 0
rbx 0x7ffff69a61a0 140737330700704
rcx 0x7fffffffc340 140737488339776
rdx 0x7ffff7e00940 140737352042816
rsi 0x7ffff6965000 140737330434048
rdi 0x0 0
rbp 0x7fffffffc210 140737488339472
rsp 0x7fffffffc1f0 140737488339440
r8 0x7fffffffc320 140737488339744
r9 0x7fffffffc400 140737488339968
r10 0x7ffff7e94b79 140737352649593
r11 0x7fffffffbe80 140737488338560
r12 0x7ffff6965000 140737330434048
r13 0x7fffffffc310 140737488339728
r14 0x7fffffffc340 140737488339776
r15 0x7fffffffc300 140737488339712
rip 0xb06dfb <js::NativeObject::lookup(js::ExclusiveContext*, jsid)+11>
=> 0xb06dfb <js::NativeObject::lookup(js::ExclusiveContext*, jsid)+11>: mov (%rdi),%rax
0xb06dfe <js::NativeObject::lookup(js::ExclusiveContext*, jsid)+14>: mov (%rax),%rax
Updated•8 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Comment 1•8 years ago
|
||
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===
The "good" changeset has the timestamp "20150923073515" and the hash "f4233421a0091c7ff9da20e917e026bf60f93c8f".
The "bad" changeset has the timestamp "20150923075616" and the hash "db4c17553be905e5d4e3106718f61f7421b91994".
Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f4233421a0091c7ff9da20e917e026bf60f93c8f&tochange=db4c17553be905e5d4e3106718f61f7421b91994
Jon, is bug 930414 a likely regressor?
Blocks: 930414
Flags: needinfo?(jcoppeard)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → jcoppeard
Flags: needinfo?(jcoppeard)
Assignee | ||
Comment 3•8 years ago
|
||
The module loader is expected to throw away module records if there is an error during instantiation, so this testcase is an invalid use of the API.
However we should make our implementation robust against such misuse.
Assignee | ||
Comment 4•8 years ago
|
||
Patch to prevent a buggy module loader trying to instantiate a module again after an error.
Attachment #8770185 -
Flags: review?(shu)
Comment 5•8 years ago
|
||
Comment on attachment 8770185 [details] [diff] [review]
bug1284486-instantiation-error
Review of attachment 8770185 [details] [diff] [review]:
-----------------------------------------------------------------
::: js/src/jit-test/tests/modules/bug-1284486.js
@@ +9,5 @@
> + c.declarationInstantiation();
> +} catch (exc) {}
> +let a = moduleRepo['a'] = parseModule("export var a = 1; export var b = 2;");
> +let d = moduleRepo['d'] = parseModule("import { a } from 'c'; a;");
> +d.declarationInstantiation();
I know this is a fuzz test and I'm fine with checking those in, but I'd like some comments on what the error during instantiation is that ultimately causes the re-instantiate error.
Attachment #8770185 -
Flags: review?(shu) → review+
Assignee | ||
Comment 6•8 years ago
|
||
(In reply to Shu-yu Guo [:shu] from comment #5)
Sure, I'll add some comments.
Pushed by jcoppeard@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/034f54c5ac43
Disallow returying ModuleDeclarationInstantiation after error r=shu
Comment 8•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
Comment 9•8 years ago
|
||
This is still reproducible in low volume on Fx50, based on the last ~3 months of crash data.
SIGNATURE | js::NativeObject::lookup
----------------------------------------
CRASH STATS | http://tinyurl.com/zefrktw
----------------------------------------
OVERVIEW | 0 crashes on nightly 52
| 1 crashes on nightly 51
| 1 crashes on aurora 51
| 0 crashes on nightly 50
| 5 crashes on aurora 50
| 39 crashes on beta 50
----------------------------------------
LAST CRASH | 2016-10-01 (on 50.0b2)
status-firefox51:
--- → affected
Assignee | ||
Comment 10•8 years ago
|
||
(In reply to Andrei Vaida, QA [:avaida] – please ni? me from comment #9)
ES6 modules aren't exposed to the web so these crashes are not due to this bug.
You need to log in
before you can comment on or make changes to this bug.
Description
•