"Assertion failure: op == JSOP_ENUMELEM || op == JSOP_ENUMCONSTELEM, at ../jsopcode.cpp"

VERIFIED FIXED in mozilla1.9.2a1

Status

()

defect
--
critical
VERIFIED FIXED
11 years ago
7 years ago

People

(Reporter: gkw, Assigned: igor)

Tracking

(Blocks 1 bug, 4 keywords)

Trunk
mozilla1.9.2a1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment)

uneval((function(){([z] = []).y >>= x}));

Assertion failure: op == JSOP_ENUMELEM || op == JSOP_ENUMCONSTELEM, at ../jsopcode.cpp:1443

This looks related to bug 453492 since the latter was just recently fixed-on-TM.
Assignee: general → igor
([z] = []).y >>= x; corresponds to the following bytecode:

00000:  newarray 0
00004:  dup
00005:  zero
00006:  getelem
00007:  bindname "z"
00010:  qnamepart "z"
00013:  enumelem
00014:  dup
00015:  getprop "y"
00018:  name "x"
00021:  rsh
00022:  setprop "y"
00025:  pop

The bug happens when DecompileDestructuring checks whether it finished its at the following code, see http://hg.mozilla.org/tracemonkey/file/e824252798be/js/src/jsopcode.cpp#l1623:

if (pc == endpc || *pc != JSOP_DUP)
    break;

/*
 * Check for SRC_DESTRUCT on this JSOP_DUP, which would mean another
 * destructuring initialiser abuts this one, and we should stop.  This
 * happens with source of the form '[a] = [b] = c'.
 */
sn = js_GetSrcNote(jp->script, pc);
if (sn && SN_TYPE(sn) == SRC_DESTRUCT)
    break;

Here the code misinterprets JSOP_DUP that dups the left-hand-side of >>= for the dup that indicates another element of the destructuring array. I guess the code must adds a source note for each dup in the destructors to distinguish this case.
This was hidden bug prior changes from the bug 460501. Before that bag landed JSOP_DUP comming from op= implementation would be prefixed in the bytecode with JSOP_GROUP. But the bug removed JSOP_GROUP and exposed this decompiler deficiency.

I nominate this bug as 1.9.1 blocker as I cannot easily see if this bug cannot be used to subvert a decompiler. In the above example the decompiler managed to misinterpret few unrelated bytecodes as a part of the decompiler sequence before hitting the local assert so to prove that the bug is not critical one has to analyze quite a few branches in the decompiler. It is more efficient to spend this time to fix this bug.
Blocks: 460501
Flags: blocking1.9.1?
Posted patch v1Splinter Review
The patch annotates JSOP_DUP that continues the destructuring pattern with SRC_CONTINUE. There is also an extra assert to ensure that that dup is either SRC_DESTRUCT or SRC_CONTINUE or noteless. I have not added an alias for reused SRC_CONTINUE since its matches the usage rather well on its own.

The patch also removes stalled comments about no longer existing JSOP_GROUP from jsparse.cpp.
Attachment #370486 - Flags: review?(brendan)
Attachment #370486 - Flags: review?(brendan) → review+
Comment on attachment 370486 [details] [diff] [review]
v1

Perfect! Hope this is the last hidden dependency on JSOP_GROUP...

/be
http://hg.mozilla.org/tracemonkey/rev/42deb57d5805
Keywords: regression
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: fixed-in-tracemonkey
Flags: blocking1.9.1? → blocking1.9.1+
http://hg.mozilla.org/mozilla-central/rev/42deb57d5805
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Verified fixed with testcase given in comment 0 on trunk and 1.9.1 with the
following debug builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre)
Gecko/20090422 Minefield/3.6a1pre ID:20090422224452

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre)
Gecko/20090422 Shiretoko/3.5b4pre ID:20090422122043
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9.2a1
Flags: in-testsuite?
Automatically extracted testcase for this bug was committed:

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