Closed
Bug 600137
Opened 14 years ago
Closed 14 years ago
"Assertion failure: proto,"
Categories
(Core :: JavaScript Engine, defect, P1)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
mozilla2.0b7
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: gkw, Assigned: brendan)
References
Details
(Keywords: assertion, regression, testcase, Whiteboard: fixed-in-tracemonkey)
try { for (var [e] = /x/ in d) { function () {} } } catch (e) {} try { let(x = Object.freeze(this, /x/)) e = #0= * .toString function y() {} } catch (e) {} asserts js debug shell on TM changeset 54700fad8cf9 without -m or -j at Assertion failure: proto, when passed in as a CLI argument.
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Reporter | ||
Comment 1•14 years ago
|
||
autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 54300:7ef107ab081e user: Brendan Eich date: Thu Sep 16 11:56:54 2010 -0700 summary: Fix shape vs. slot management under putProperty, plus related layering and error reporting fixes (596805, r=jorendorff).
Blocks: 596805
Assignee | ||
Comment 2•14 years ago
|
||
(In reply to comment #1) > autoBisect shows this is probably related to the following changeset: > > The first bad revision is: > changeset: 54300:7ef107ab081e > user: Brendan Eich > date: Thu Sep 16 11:56:54 2010 -0700 > summary: Fix shape vs. slot management under putProperty, plus related > layering and error reporting fixes (596805, r=jorendorff). The bug is much older. It is a combination of anyname having no global parent with standard built-ins, and the ancient (to the dawn of time: Mocha in 1995) SpiderMonkey behavior of giving built-in functions lazy .prototype properties. Patch is over in the blocking bug, bug 445319. I'll put a testcase for this bug in an update to that bug's patch tomorrow. /be
Assignee: general → brendan
OS: Linux → All
Priority: -- → P1
Hardware: x86 → All
Target Milestone: --- → mozilla2.0b7
Assignee | ||
Updated•14 years ago
|
Status: NEW → ASSIGNED
Updated•14 years ago
|
blocking2.0: ? → betaN+
Assignee | ||
Comment 3•14 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/812a37500dda /be
Whiteboard: fixed-in-tracemonkey
Assignee | ||
Comment 4•14 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/376dc8dc6596 (forgot to hg add) /be
Assignee | ||
Comment 5•14 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/6ecaaddfc56e (JSOPTION_ANONFUNFIX, grrr!) Gary: these fuzzer-generated shell tests should not rely on lack of JSOPTION_ANONFUNFIX, right? I thought you had a fuzzer option or something. /be
Comment 6•14 years ago
|
||
The fuzzer tries to keep anonfunfix on, but the reduction steps don't. Are we going to enable it by default in the shell?
Assignee | ||
Comment 7•14 years ago
|
||
Bug 595555. I was burned so I will take and fix now. /be
Assignee | ||
Comment 8•14 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/bd0030c21d3f It would be cool if the browser jsreftest harness sported an emulation of the shell's evalcx function. This seems doable but I couldn't find any sign of it. Bob, Blake: ideas or leads? /be
Comment 9•14 years ago
|
||
The necessary code to implement evalcx could be placed in the top level browser.js script to provide the functionality. Is it possible to emulate evalcx <https://developer.mozilla.org/en/Introduction_to_the_JavaScript_shell#evalcx%28string.5b.2c_object.5d%29> using Components.utils.evalInSandbox <https://developer.mozilla.org/en/Components.utils.evalInSandbox> with sufficient fidelity? It will need privileges to invoke it however. Is there a different functionality that doesn't require elevated privileges? jmaher: what is the current strategy for dealing with the need for elevated privileges?
Assignee | ||
Comment 10•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/bd0030c21d3f http://hg.mozilla.org/mozilla-central/rev/6ecaaddfc56e http://hg.mozilla.org/mozilla-central/rev/376dc8dc6596 http://hg.mozilla.org/mozilla-central/rev/812a37500dda /be
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 11•14 years ago
|
||
reftest runs in chrome, so it doesn't need special powers. Assuming we ran it in content, we have the 'sandbox' which would effectively give a cache of data during load time which is accessible by the tests. For mochitests which are run in content and need privileges, we are looking at doing a special powers object: https://bugzilla.mozilla.org/show_bug.cgi?id=582472
Comment 12•11 years ago
|
||
A testcase for this bug was automatically identified at js/src/tests/js1_8_5/regress/regress-600137.js.
Flags: in-testsuite+
Reporter | ||
Comment 13•11 years ago
|
||
Testcases have been landed by virtue of being marked in-testsuite+ -> VERIFIED as well.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•