610088 - "Assertion failure: script->main <= target && target < script->code + script->length" with evalcx, Object.seal(this), proxy

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

Attachment: js shell testcase

Assertion failure: script->main <= target && target < script->code + script->length, at js/src/jsopcode.cpp:5524

The first bad revision is:
changeset:   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).

Comment 1

[Jesse Ruderman]

Attachment: stack trace

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Fixed by bug 600642.

autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   60012:9074de2454dc
user:        Andreas Gal
date:        Mon Jan 10 11:42:11 2011 -0800
summary:     Rename Proxy enumerateOwn to keys (bug 600642, r=jorendorff,brendan).

Comment 3

[Jesse Ruderman]

No, that patch only renamed enumerateOwn to keys ;)

Comment 4

[Jesse Ruderman]

Attachment: js shell testcase

Comment 5

[Andreas Gal :gal]

Why .x?

Comment 6

[David Mandelin [:dmandelin]]

(In reply to comment #5)
> Why .x?

The bug looks like an assertion failure in the decompiler for some obscure code. Seems lower priority than our existing softblockers.

Comment 7

[Andreas Gal :gal]

Without some more detailed look I would be worried to just postpone this indefinitely, in particular with a public visible test case. softblocker instead? I wouldn't hold a release over this, but I would prioritize this over any non-FF4-blocker work.

Comment 8

[David Mandelin [:dmandelin]]

(In reply to comment #7)
> Without some more detailed look I would be worried to just postpone this
> indefinitely, in particular with a public visible test case. softblocker
> instead? I wouldn't hold a release over this, but I would prioritize this over
> any non-FF4-blocker work.

Sure, I was on the border on this one.

Comment 9

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: fix

This was a quick fix. Here's what happened:
- We seal |this|
- Defining |y| in the last line causes an error
- To print the error message, we try to decompile the value of |x|
- When we try to enumerate the properties of |x|, we call its keys method, which is really Object.getPrototypeOf
- This function expects more than one argument, so it throws an error
- To print *this* error, we call DecompileValueGenerator from the prologue of the |const y| script (I think)
- DecompileValueGenerator freaks out because you're not supposed to call it from the prologue

The patch just uses the fallback case in DecompileValueGenerator when it's called from the prologue. The fallback case calls ValueToString, which seem fine here.

Comment 10

[Andreas Gal :gal]

Thanks for the quick fix. Cool.

Comment 11

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

http://hg.mozilla.org/tracemonkey/rev/df4c38d9144e

Comment 12

[Chris Leary [:cdleary] (not checking bugmail)]

cdleary-bot mozilla-central merge info:
http://hg.mozilla.org/mozilla-central/rev/df4c38d9144e

Comment 13

[Christian Holler (:decoder)]

Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929