755813 - IonMonkey: Inconsistent DVG error message

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

./js --no-jm

function f(o) {
    for (var z in o) {}
    Object.seal(o)
}
for (var y = 0; y < 20; ++y) {
    try {
        f("" + y)
    } catch (e) {
        print(y + ' ' + e)
    }
}

...
11 TypeError: o is not an object
12 TypeError: "12" is not an object     <-- ?
13 TypeError: o is not an object
...

Comment 1

[Jesse Ruderman]

Due to skipped revisions, the first bad revision could be any of:

changeset:   300ac3d58291
user:        David Anderson
date:        Thu Apr 19 15:02:11 2012 -0700
summary:     Enable JITs and type inference by default, and give Ion first chance (bug 724751, r=jandem).

changeset:   de015aff650d
user:        David Anderson
date:        Thu Apr 19 15:02:47 2012 -0700
summary:     Enable IonMonkey in the browser, and introduce an about:config option to pref it off (bug 745390, r=dmandelin).

changeset:   9e64f779b611
user:        David Anderson
date:        Thu Apr 19 16:57:58 2012 -0700
summary:     Disable TypeScript::SetScope (bug 747226, r=bhackett).

changeset:   bc1833f2111e
user:        Christian Holler
date:        Mon Apr 23 17:32:32 2012 +0200
summary:     Bug 747902 - Add --ion, -n and -m flags back for compatibility

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

There may be something we can do about this, but I'm not sure yet. For this specific case, probably. IonMonkey doesn't guarantee full stack reification from safepoints which is what would be needed to make error messages always match the interpreter.

CC'ing Luke for advice.

Comment 3

[Luke Wagner [:luke]]

DVG search stack is goofy and we should eventually remove it: it searches the stack for a given value and it is easy to break.  To get reproducible testing, perhaps we could have a special build mode where JSDVG_SEARCH_STACK doesn't actually search the stack and always goes to the print-the-value fallback?

Comment 4

[Christian Holler (:decoder)]

(In reply to Luke Wagner [:luke] from comment #3)
> To get reproducible
> testing, perhaps we could have a special build mode where JSDVG_SEARCH_STACK
> doesn't actually search the stack and always goes to the print-the-value
> fallback?

You could use the --enable-more-deterministic build mode for that :)

Comment 5

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

Before changeset a85c0f30cdfa, it showed:

0 TypeError: o is not an object
1 TypeError: o is not an object
2 TypeError: o is not an object
3 TypeError: o is not an object
/snip

but after changeset a5c50066ecbb, it showed:

0 TypeError: "0" is not an object
1 TypeError: "1" is not an object
2 TypeError: "2" is not an object
3 TypeError: "3" is not an object
/snip

The fix likely came before a85c0f30cdfa since the discrepancy no longer existed, in any case, this is WFM.