Closed
Bug 484769
Opened 16 years ago
Closed 16 years ago
"Assertion failure: pn->pn_type != TOK_DEFSHARP, at ../jsemit.cpp:3575"
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
mozilla1.9.2a1
People
(Reporter: gkw, Assigned: igor)
References
Details
(Keywords: assertion, testcase, verified1.9.1, Whiteboard: fixed-in-tracemonkey)
Attachments
(1 file)
880 bytes,
patch
|
brendan
:
review+
|
Details | Diff | Splinter Review |
[] = [, #1=x]
Assertion failure: pn->pn_type != TOK_DEFSHARP, at ../jsemit.cpp:3575
(Debug js shell, without -j, feed it in via a file, i.e. ./js file.js to reproduce)
Assigning to Igor as requested. The last Sharp-related assertion just fixed is bug 369696, which is [sg:critical?], so keeping this security-sensitive just-in-case.
Flags: blocking1.9.1?
Assignee | ||
Comment 1•16 years ago
|
||
The assert comes from the bug 368213 and is supposed to ensure that EmitGroupAssignment is not called when the array literal has a sharp variable definition. For that the assert checks that none of children nodes for the array is a DEFSHARP parse node.
But this is not the right assert. The sharp definition for the array is signaled just by the first element of the children list, the rest of sharps are unrelated.
The bottom line: the assert should be fixed and there is no consequences of its violation for non-debug code.
Group: core-security
Depends on: 368213
Assignee | ||
Comment 2•16 years ago
|
||
The incorrect assert was introduced in the bug 368213.
Assignee | ||
Comment 3•16 years ago
|
||
The fix checks that any TOK_SHARPDEF node among array elements has a kid and, as such, is unrelated to the array itself.
Attachment #369262 -
Flags: review?(brendan)
Comment 4•16 years ago
|
||
Comment on attachment 369262 [details] [diff] [review]
v1
D'oh! Thanks,
/be
Attachment #369262 -
Flags: review?(brendan) → review+
Assignee | ||
Comment 5•16 years ago
|
||
landed to TM - http://hg.mozilla.org/tracemonkey/rev/b893df7318c5
Whiteboard: fixed-in-tracemonkey
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Comment 6•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 7•16 years ago
|
||
Keywords: fixed1.9.1
Comment 8•16 years ago
|
||
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
Keywords: fixed1.9.1 → verified1.9.1
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2a1
Reporter | ||
Updated•16 years ago
|
Flags: in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•