Assertion failure: vp[1].isObject(), at vm/Interpreter.cpp

RESOLVED FIXED in mozilla37

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: gkw, Assigned: Waldo)

Tracking

(Blocks: 2 bugs, {assertion, regression, testcase})

Trunk
mozilla37
x86_64
Mac OS X
assertion, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox37 affected)

Details

(Whiteboard: [jsbugmon:update])

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
// Randomly chosen test: jit-test/tests/baseline/bug843886.js
__proto__["__noSuchMethod__"] = __proto__;
// Randomly chosen test: jit-test/tests/auto-regress/bug745158.js
[] = 1

asserts js debug shell on m-c changeset 54e902f5e85d with --fuzzing-safe --no-threads --ion-eager at Assertion failure: vp[1].isObject(), at vm/Interpreter.cpp.

Debug 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 --enable-optimize --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

=== Tinderbox Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20141226092431" and the hash "88087d21d868".
The "bad" changeset has the timestamp "20141226095034" and the hash "4fd307cbb9d9".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=88087d21d868&tochange=4fd307cbb9d9

Waldo, is bug 603201 a likely regressor?
Flags: needinfo?(jwalden+bmo)
(Reporter)

Comment 1

3 years ago
Created attachment 8541836 [details]
stack

(lldb) bt
* thread #1: tid = 0x18c753, 0x0000000100631aee js-dbg-opt-64-dm-nsprBuild-darwin-54e902f5e85d`js::Invoke(cx=<unavailable>, args=<unavailable>, construct=<unavailable>) + 1262 at Interpreter.cpp:471, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000100631aee js-dbg-opt-64-dm-nsprBuild-darwin-54e902f5e85d`js::Invoke(cx=<unavailable>, args=<unavailable>, construct=<unavailable>) + 1262 at Interpreter.cpp:471
    frame #1: 0x000000010061cb8f js-dbg-opt-64-dm-nsprBuild-darwin-54e902f5e85d`js::Invoke(cx=0x0000000101b14f60, thisv=<unavailable>, fval=<unavailable>, argc=<unavailable>, argv=<unavailable>, rval=<unavailable>) + 815 at Interpreter.cpp:558
    frame #2: 0x0000000100232b9c js-dbg-opt-64-dm-nsprBuild-darwin-54e902f5e85d`js::jit::DoCallFallback(cx=0x0000000101b14f60, frame=<unavailable>, stub_=<unavailable>, argc=0, vp=0x00007fff5fbfecd8, res=<unavailable>) + 2204 at BaselineIC.cpp:9435
    frame #3: 0x0000000101ac7573
(lldb)
(Assignee)

Comment 3

3 years ago
Created attachment 8543076 [details] [diff] [review]
Don't call a __noSuchMethod__ hook if the receiver for the property-get isn't an object (again)

Bleh, apparently we go out of our way to not call __noSuchMethod__ if the value the method-call was requested upon was a primitive.  And the current code expects this, more or less.  Sigh.

The assertion could conceivably be removed, but there's a bunch of JIT nonsense for __noSuchMethod__ that might need adjustment for consistency, and I'm loathe to put lipstick on that pig.  So fork the object/primitive receiver code a little harder to deal for now.  Yes, it's a little copypasta, but I'd rather have to deal with entirely separate code in the course of fixing this, even if it means a little copypasta, than revert to the old shared-code system where we had a |wasObject| argument making the algorithm uglier and harder to understand.
Attachment #8543076 - Flags: review?(efaustbmo)
(Assignee)

Updated

3 years ago
Assignee: nobody → jwalden+bmo
Status: NEW → ASSIGNED
(Assignee)

Updated

3 years ago
Flags: needinfo?(jwalden+bmo)

Comment 4

3 years ago
Comment on attachment 8543076 [details] [diff] [review]
Don't call a __noSuchMethod__ hook if the receiver for the property-get isn't an object (again)

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

Yeahp. Not much for it, I guess. r=me
Attachment #8543076 - Flags: review?(efaustbmo) → review+
https://hg.mozilla.org/mozilla-central/rev/2639ebee70ab
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
You need to log in before you can comment on or make changes to this bug.