Assertion failure: !uses->next->next && uses->next->popped && script->code[uses->next->offset] == JSOP_SWAP, at ../jsanalyze.h:1064

RESOLVED FIXED in mozilla13

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: decoder, Assigned: bhackett)

Tracking

(Blocks: 1 bug, {assertion, regression, testcase})

Trunk
mozilla13
assertion, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: js-triage-needed)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
The following test asserts on mozilla-central revision 4de07a341aab (options -m -n -a):


[].__proto__();
If I had to guess, I'm betting this has to do with the JSOP_QNAMEPART fugliness for property accesses for __proto__.  h8
This has not been fixed on m-c changeset 7c7d2a8db7ff (which has bug 716713 included)

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   84036:7ab4f1ebc7cc
user:        Brian Hackett
date:        Mon Jan 09 06:29:50 2012 -0800
summary:     Backout 54cd89b0f1fa (bug 712714 backout).  Talos will probably report fake regressions for this patch, do not back out for this reason.
Blocks: 712714
Keywords: regression
OS: Linux → All
Hardware: x86_64 → All
(Assignee)

Comment 3

6 years ago
Created attachment 587907 [details] [diff] [review]
rm fugliness

Yeah, it's the __proto__ special casing.  This bug removes that stuff entirely.  It seems only necessary so that the interpreter does not have to check for __proto__ when doing GetProtoIfDenseArray.  Interpreter optimizations are no longer necessary/justifiable, and while PICs should still be able to do this stuff they can test for __proto__ before generating code.
Assignee: general → bhackett1024
Attachment #587907 - Flags: review?(jwalden+bmo)
(Assignee)

Comment 4

6 years ago
(In reply to Brian Hackett (:bhackett) from comment #3)
> Interpreter optimizations are no longer necessary/justifiable

Overstated this a bit.  Having significant complexity to occasionally save a few cycles while interpreting is not good.
Comment on attachment 587907 [details] [diff] [review]
rm fugliness

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

And there was much rejoicing.
Attachment #587907 - Flags: review?(jwalden+bmo) → review+
(Assignee)

Comment 6

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/5cdf9574bede
(Assignee)

Comment 7

6 years ago
Backed out for not building on any platforms except the ones I tested on.

https://hg.mozilla.org/integration/mozilla-inbound/rev/408ab9247ef1
Duplicate of this bug: 722592
(Assignee)

Comment 9

6 years ago
Created attachment 598057 [details] [diff] [review]
weaken assert

Unfortunately the QNAMEPART stuff is also necessary for correct behavior of __proto__ on primitives (which should get e.g. Number.prototype instead of Object.prototype) and there doesn't seem to be an easy/efficient way to fix this.  So here's a patch which weakens the assert so that the goofy SWAP; SWAP sequence of bytecodes emitted here is passed through.
Attachment #598057 - Flags: review?(jwalden+bmo)
Attachment #598057 - Flags: review?(jwalden+bmo) → review+
(Assignee)

Comment 10

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/f2106545d9b3
https://hg.mozilla.org/mozilla-central/rev/f2106545d9b3
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
(Reporter)

Comment 12

5 years ago
Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.