Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now) Reporter
	Description • 15 years ago

delete this.uneval
function g(code) {
    var f = new Function(code)
    try {
        f()
    } catch (r) {}
    delete this.uneval
}
g("\
  [\
    []\
  ].some(function (a) {\
    this.w = function () {\
      a\
    }\
  })\
")

asserts js debug shell without -j on TM tip at Assertion failure: !generic(), at ../jsscope.h:426

	Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now) Reporter
	Comment 1 • 15 years ago

Tested on 64-bit Linux.

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   41518:539d04cccb8b
user:        Jason Orendorff
date:        Fri Apr 30 08:29:04 2010 -0500
summary:     Bug 560998 - Assertion failure: entry->vword.toObject() == JSVAL_TO_OBJECT(v). r=brendan.

	Jason Orendorff [:jorendorff] Assignee
	Comment 2 • 15 years ago

function c(a) {                  // make the global GENERIC
    this.w = function () { a; };
}
c(0);                            // after this, the global scope has both
                                 // BRANDED and GENERIC bits set
delete this.uneval;
delete this.uneval;              // JS_ResolveStandardClass redefines uneval
                                 // (in order to delete it again), triggering bug

	Jason Orendorff [:jorendorff] Assignee
	Comment 3 • 15 years ago

It is a little weird that branded() asserts this way instead of just testing both bits. But ok.

	Jason Orendorff [:jorendorff] Assignee
	Comment 4 • 15 years ago

The question, really, is what should happen when we reach JSOP_UNBRAND or UNBRANDTHIS and the operand is already branded. Here is my guess.

I think overflowing rt->shapeGen here is harmless, or at least there's nothing to be done about it. I can comment that if it would help understanding.

	Brendan Eich [:brendan]
	Comment 5 • 15 years ago

Even simpler: once branded, there's no point in being generic, since the shape has already evolved unpredictably (only singleton objects are cacheable). So how about restricting state evolution to

 {} -> {branded} -(would-be generic)->{branded}

or

 {} -> {generic} -(would-be branded)->{generic}

/be

	Brendan Eich [:brendan]
	Comment 6 • 15 years ago

Jason, should we stall this while I work on bug 558451? Did you plan to do something like what is proposed in comment 5?

/be

	Jason Orendorff [:jorendorff] Assignee
	Comment 7 • 15 years ago

Sorry. The weekend was crazy, and I was on a plane all yesterday.

I think we should push this unless it'll cause merge pains for you.

	Brendan Eich [:brendan]
	Comment 8 • 15 years ago

Don't worry about the merge pain, but please do respond to the proposed reduced state machine in comment 5.

/be

	Jason Orendorff [:jorendorff] Assignee
	Comment 9 • 15 years ago

That's what v3 is, I think.

	Brendan Eich [:brendan]
	Comment 10 • 15 years ago

Comment on attachment 447339 [details] [diff] [review]
v3

Thanks, missed v3 for some reason there...

/be

	Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now) Reporter
	Comment 11 • 15 years ago

Just helping out...

http://hg.mozilla.org/tracemonkey/rev/331702c6884f

	Robert Sayre
	Comment 12 • 15 years ago

http://hg.mozilla.org/mozilla-central/rev/331702c6884f

	Christian Holler (:decoder)
	Comment 13 • 12 years ago

A testcase for this bug was automatically identified at js/src/tests/js1_8_5/regress/regress-567152.js.

	Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now) Reporter
	Comment 14 • 12 years ago

Testcases have been landed by virtue of being marked in-testsuite+ -> VERIFIED as well.