Closed Bug 1095870 Opened 7 years ago Closed 7 years ago

Assertion failure: setPropStub->holderShape() != holder->lastProperty() || setPropStub->shape() != receiverShape (Why didn't we end up using this stub?), at jit/BaselineIC.cpp

Categories

(Core :: JavaScript Engine: JIT, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox36 --- affected

People

(Reporter: gkw, Assigned: bzbarsky)

References

Details

(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update])

Attachments

(2 files)

for (var j = 0; j < 2; j++) {
    isPrototypeOf().__proto__ = 0
}

asserts js debug shell on m-c changeset eb0d3b3c0b22 with --ion-eager --no-threads at Assertion failure: setPropStub->holderShape() != holder->lastProperty() || setPropStub->shape() != receiverShape (Why didn't we end up using this stub?), at jit/BaselineIC.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 "20141106201809" and the hash "e70ad67d1c7b".
The "bad" changeset has the timestamp "20141106204315" and the hash "7bf195ca830a".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e70ad67d1c7b&tochange=7bf195ca830a

Boris, is bug 1089050 a possible regressor?
Flags: needinfo?(bzbarsky)
> Boris, is bug 1089050 a possible regressor?

Sure, since it added the assert.

Here's a simpler testcase:

for (var j = 0; j < 2; j++) {
    (false).__proto__ = 0
}
So I bet the reason we didn't end up using the stub is that the stub sees the primitive value.  Then we skip the stub, land in DoSetPropFallback, try to generate a new stub, and end up in this code.

I can loosen up the assert for objects that are wrappers around primitives, but it seems more correct to me to not generate setter stubs at all when lhs is a primitive....
Flags: needinfo?(bzbarsky)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Comment on attachment 8519382 [details] [diff] [review]
Don't generate baseline set IC stubs for primitive 'this' values, since all the stubs only work on objects

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

So in this case we attached a stub that will never hit? Nice find.
Attachment #8519382 - Flags: review?(jdemooij) → review+
> So in this case we attached a stub that will never hit?

Well, it'll hit if an actual Boolean object comes through.  But in practice, that's never, yes.
https://hg.mozilla.org/mozilla-central/rev/ca8e506e5be0
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.