Closed Bug 1289040 Opened 3 years ago Closed 3 years ago

Crash [@ js::Wrapper::wrappedObject] or Assertion failure: IsWrapper(&args[0].toObject()), at js/src/vm/SelfHosting.cpp:206

Categories

(Core :: JavaScript Engine, defect, critical)

x86_64
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
Tracking Status
firefox49 --- unaffected
firefox-esr45 --- unaffected
firefox50 --- verified

People

(Reporter: gkw, Assigned: till)

References

(Blocks 2 open bugs)

Details

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

Crash Data

Attachments

(2 files)

The following testcase crashes on mozilla-central revision e0bc88708ffe (build with --enable-debug --enable-more-deterministic, run with --fuzzing-safe --no-threads --no-baseline --no-ion):

// jsfunfuzz-generated
Promise.prototype.then = newGlobal().Promise.prototype.then;
// Adapted from randomly chosen test: js/src/tests/ecma_6/Promise/promise-all.js
new Promise(function f() {
    return f()
}).then();


Backtrace:

0   js-dbg-64-dm-clang-darwin-e0bc88708ffe	0x000000010e0df5e3 intrinsic_UnsafeCallWrappedFunction(JSContext*, unsigned int, JS::Value*) + 1187 (SelfHosting.cpp:206)
1   js-dbg-64-dm-clang-darwin-e0bc88708ffe	0x000000010e0526de js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) + 286 (jscntxtinlines.h:233)
2   js-dbg-64-dm-clang-darwin-e0bc88708ffe	0x000000010e041c72 js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) + 690 (Interpreter.cpp:441)
3   js-dbg-64-dm-clang-darwin-e0bc88708ffe	0x000000010e0393fe Interpret(JSContext*, js::RunState&) + 37342 (Interpreter.cpp:2873)
4   js-dbg-64-dm-clang-darwin-e0bc88708ffe	0x000000010e03014f js::RunScript(JSContext*, js::RunState&) + 511 (Interpreter.cpp:399)
/snip

For detailed crash information, see attachment.
This also crashes opt builds at js::Wrapper::wrappedObject.
Crash Signature: [@ js::Wrapper::wrappedObject]
Summary: Assertion failure: IsWrapper(&args[0].toObject()), at js/src/vm/SelfHosting.cpp:206 → Crash [@ js::Wrapper::wrappedObject] or Assertion failure: IsWrapper(&args[0].toObject()), at js/src/vm/SelfHosting.cpp:206
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160721025620" and the hash "ae502e2271f2464d92ef398d7c8c43f835865bd6".
The "bad" changeset has the timestamp "20160721033920" and the hash "efcf012e6cfc24413bea5078650e4528be361205".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ae502e2271f2464d92ef398d7c8c43f835865bd6&tochange=efcf012e6cfc24413bea5078650e4528be361205

Till, this seems related to Promises.
Blocks: 911216
Flags: needinfo?(till)
In an opt build:

(lldb) dis -p
js-64-dm-clang-darwin-e0bc88708ffe`js::Wrapper::wrappedObject:
->  0x1004cb46e <+14>: andq   (%rcx), %rax
    0x1004cb471 <+17>: retq
    0x1004cb472 <+18>: nopw   %cs:(%rax,%rax)

js-64-dm-clang-darwin-e0bc88708ffe`js::CheckedUnwrap:
    0x1004cb480 <+0>:  pushq  %r15
(lldb) register read $rc
error: Invalid register name 'rc'.
(lldb) register read $rcx
     rcx = 0x0000000000000000
(lldb) register read $rax
     rax = 0x00007fffffffffff
(lldb)

I'm not sure if this is entirely benign so I'll set it s-s to be safe.
Group: javascript-core-security
More complications in dealing with wrapped promises :(
Assignee: nobody → till
Status: NEW → ASSIGNED
Flags: needinfo?(till)
Attachment #8775114 - Flags: review?(efaustbmo)
Comment on attachment 8775114 [details] [diff] [review]
Properly handle non-wrapped Promise hook functions in UnwrappedPerformPromiseThen

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

Blech. I'm starting to feel like my initial review sucked. I'm not sure I would have found this, as the interaction is quite complicated, but it's sad that we now have three or four of these side cases documented.

::: js/src/builtin/Promise.js
@@ +843,5 @@
> +            // passed to `NewPromiseCapability` is from the same global as the
> +            // Promise object on which `Promise_then` was called, but where
> +            // `Promise_then` is from a different global, so we end up here.
> +            // In that case, the `resolve` and `reject` functions aren't
> +            // wrappers in the current global.

sweet googly moogly.
Attachment #8775114 - Flags: review?(efaustbmo) → review+
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
JSBugMon: The testcase found in this bug no longer reproduces (tried revision 9ec789c0ee5b).
This landed as https://hg.mozilla.org/integration/mozilla-inbound/rev/9e9fcc1feac2 on inbound and then on m-c:
https://hg.mozilla.org/mozilla-central/rev/9e9fcc1feac2
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
JSBugMon: This bug has been automatically verified fixed.
Group: javascript-core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.