Closed Bug 600137 Opened 14 years ago Closed 14 years ago

"Assertion failure: proto,"

Categories

(Core :: JavaScript Engine, defect, P1)

defect

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.
blocking2.0: --- → ?
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
Depends on: 445319
(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
Status: NEW → ASSIGNED
blocking2.0: ? → betaN+
http://hg.mozilla.org/tracemonkey/rev/812a37500dda

/be
Whiteboard: fixed-in-tracemonkey
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
The fuzzer tries to keep anonfunfix on, but the reduction steps don't.  Are we going to enable it by default in the shell?
Bug 595555. I was burned so I will take and fix now.

/be
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
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?
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
A testcase for this bug was automatically identified at js/src/tests/js1_8_5/regress/regress-600137.js.
Flags: in-testsuite+
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.