Closed Bug 1219408 Opened 6 years ago Closed 6 years ago

Crash [@ js::Execute] or [@ JSObject::getClass] or [@ js::ModuleObject::evaluate] or Assertion failure: scope, at builtin/ModuleObject.cpp

Categories

(Core :: JavaScript Engine, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla45
Tracking Status
firefox44 --- affected
firefox45 --- fixed
b2g-v2.5 --- fixed

People

(Reporter: gkw, Assigned: jonco)

References

Details

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

Crash Data

Attachments

(3 files)

// Adapted from randomly chosen test: js/src/jit-test/tests/modules/bug1210391.js
let moduleRepo = new Map();
setModuleResolveHook(function(module, specifier) {
    return moduleRepo[specifier];
});
moduleRepo['a'] = parseModule("export var a = 2;");
moduleRepo['c'] = parseModule("export * from 'a';");
let d = moduleRepo['d'] = parseModule("import {} from 'c';");
d.evaluation();

asserts js debug shell on m-c changeset fc706d376f06 with --fuzzing-safe --no-threads --no-ion --no-baseline at Assertion failure: scope, at builtin/ModuleObject.cpp

Configure options:

CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar AUTOCONF=/usr/local/Cellar/autoconf213/2.13/bin/autoconf213 sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-debug --disable-threadsafe --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

python -u ~/funfuzz/js/compileShell.py -b "--enable-debug --enable-more-deterministic" -r fc706d376f06

=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20151021063502" and the hash "ab8d2508c6ea2e1a0869f62c668eb0dee6709e42".
The "bad" changeset has the timestamp "20151021065531" and the hash "935cdbf4fcf571496793fb06a5a9e1f90050e092".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ab8d2508c6ea2e1a0869f62c668eb0dee6709e42&tochange=935cdbf4fcf571496793fb06a5a9e1f90050e092

Jon, is bug 930414 a likely regressor?
Flags: needinfo?(jcoppeard)
Attached file stack
(lldb) bt 5
* thread #1: tid = 0x2bfe24, 0x00000001001570b4 js-dbg-64-dm-darwin-fc706d376f06`js::ModuleObject::evaluate(cx=<unavailable>, self=<unavailable>, rval=<unavailable>) + 292 at ModuleObject.cpp:788, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001001570b4 js-dbg-64-dm-darwin-fc706d376f06`js::ModuleObject::evaluate(cx=<unavailable>, self=<unavailable>, rval=<unavailable>) + 292 at ModuleObject.cpp:788
    frame #1: 0x0000000100755e58 js-dbg-64-dm-darwin-fc706d376f06`intrinsic_EvaluateModule(cx=0x0000000102c45400, argc=<unavailable>, vp=0x0000000102f652d0) + 136 at SelfHosting.cpp:1425
    frame #2: 0x000000010066c232 js-dbg-64-dm-darwin-fc706d376f06`js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) [inlined] js::CallJSNative(cx=0x0000000102c45400, native=(js-dbg-64-dm-darwin-fc706d376f06`intrinsic_EvaluateModule(JSContext*, unsigned int, JS::Value*) at SelfHosting.cpp:1421))(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) + 174 at jscntxtinlines.h:235
    frame #3: 0x000000010066c184 js-dbg-64-dm-darwin-fc706d376f06`js::Invoke(cx=0x0000000102c45400, args=0x00007fff5fbfd2a8, construct=<unavailable>) + 596 at Interpreter.cpp:489
    frame #4: 0x0000000100686c65 js-dbg-64-dm-darwin-fc706d376f06`Interpret(cx=<unavailable>, state=0x00007fff5fbfd7d0) + 49301 at Interpreter.cpp:2810
(lldb)
Attached file Opt stack
(lldb) bt 5
* thread #1: tid = 0x2bffaa, 0x00000001003f4242 js-64-dm-darwin-fc706d376f06`js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) [inlined] JSObject::getClass() const at jsobj.h:122, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001003f4242 js-64-dm-darwin-fc706d376f06`js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) [inlined] JSObject::getClass() const at jsobj.h:122
    frame #1: 0x00000001003f4242 js-64-dm-darwin-fc706d376f06`js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) [inlined] JSObject::getOps(this=<unavailable>) const at jsobj.h:131
    frame #2: 0x00000001003f4242 js-64-dm-darwin-fc706d376f06`js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) at jsobj.h:1105
    frame #3: 0x00000001003f4242 js-64-dm-darwin-fc706d376f06`js::Execute(cx=0x0000000103079400, script=<unavailable>, scopeChainArg=<unavailable>, rval=0x000000010434c2d0) + 210 at Interpreter.cpp:738
    frame #4: 0x00000001000da481 js-64-dm-darwin-fc706d376f06`js::ModuleObject::evaluate(cx=<unavailable>, self=<unavailable>, rval=<unavailable>) + 177 at ModuleObject.cpp:790
(lldb)
This crashes js opt shell too.

(lldb) dis -p
js-64-dm-darwin-fc706d376f06`js::Execute:
->  0x1003f4242 <+210>: movq   (%rdx), %rax
    0x1003f4245 <+213>: movq   (%rax), %rax
    0x1003f4248 <+216>: movq   0x130(%rax), %rcx
    0x1003f424f <+223>: testq  %rcx, %rcx
(lldb) register read $rdx
     rdx = 0x0000000000000000
(lldb) register read $rax
     rax = 0x00007fff5fbfd480
(lldb)

Is it trying to access 0x00007fff5fbfd480? Setting s-s in case this is.
Group: javascript-core-security
Crash Signature: [@ js::Execute]
Keywords: crash
Summary: Assertion failure: scope, at builtin/ModuleObject.cpp → Crash [@ js::Execute] or Assertion failure: scope, at builtin/ModuleObject.cpp
Crash Signature: [@ js::Execute] → [@ js::Execute] [@ JSObject::getClass]
Summary: Crash [@ js::Execute] or Assertion failure: scope, at builtin/ModuleObject.cpp → Crash [@ js::Execute] or [@ JSObject::getClass] or Assertion failure: scope, at builtin/ModuleObject.cpp
(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #3)
> ->  0x1003f4242 <+210>: movq   (%rdx), %rax
> 
> Is it trying to access 0x00007fff5fbfd480? Setting s-s in case this is.

This is reading from the address in rdx and storing the result in rax.  So it's a null pointer dreference.
Flags: needinfo?(jcoppeard)
parseModule() is not available outside the shell, so clearing s-s.
Group: javascript-core-security
The problem is that module evaluation is being triggered before module declaration instantiation.  This can only happen due to a bug in the module loader, but I guess this does need an error rather than an assert.
Assignee: nobody → jcoppeard
Attachment #8680575 - Flags: review?(shu)
Comment on attachment 8680575 [details] [diff] [review]
bug1219408-module-eval-assert

Review of attachment 8680575 [details] [diff] [review]:
-----------------------------------------------------------------

tricksy fuzzers
Attachment #8680575 - Flags: review?(shu) → review+
js::ModuleObject::evaluate is sometimes on the stack for other testcase variants.
Crash Signature: [@ js::Execute] [@ JSObject::getClass] → [@ js::Execute] [@ JSObject::getClass] [@ js::ModuleObject::evaluate]
Summary: Crash [@ js::Execute] or [@ JSObject::getClass] or Assertion failure: scope, at builtin/ModuleObject.cpp → Crash [@ js::Execute] or [@ JSObject::getClass] or [@ js::ModuleObject::evaluate] or Assertion failure: scope, at builtin/ModuleObject.cpp
https://hg.mozilla.org/mozilla-central/rev/72a8903bd4bf
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
You need to log in before you can comment on or make changes to this bug.