785358 - Assertion failure: fe->isType(type), at methodjit/Compiler.cpp:7623

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following test asserts on mozilla-central revision ad7963c93bd8 (options -m -a -n):


try {
a = []
function f(o) {
    o[5] = {}
}
    with(a) f()
} catch(exc1) {}
evaluate("f({});");

Comment 1

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   103051:bf07c6253287
user:        Brian Hackett
date:        Wed Aug 22 12:28:34 2012 -0600
summary:     Allow purging analysis-temporary while retaining jitcode, bug 778724. r=luke

Comment 2

[Christian Holler (:decoder)]

CCing bhackett and luke by comment 1.

Comment 3

[Brian Hackett [Laid off!]]

Attachment: patch

Bug 778724 is innocent here, the different recompilation pattern it introduces exposed the bug.  This is a regression from bug 731398; this bug allows initializers in run-once scripts to produce objects with singleton type, which TI will not try to guess at the result until the initializer actually runs.  But JM will still treat these opcodes as definitely producing objects, a refinement of the type information which it shouldn't be doing.

Comment 4

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1dce4807ad01

Comment 5

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 1b0b56afa33a).

Comment 6

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/1dce4807ad01

Comment 7

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 8

[Matt Wobensmith [:mwobensmith][:matt:]]

Confirmed assert on 2012-8-24, nightly jsshell

I can confirm fixed (or unable to reproduce) on jsshell for beta/Aurora/nightly, 2012-11-20. However, above comments say it was only fixed for 18. 

Is this correct? What would we expect to see here?

Comment 9

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

Assuming affected for 17 - decoder, do you mind rechecking if 17 is still affected?

(wontfix'ing for 16 since 17 is out of the door)

Comment 10

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically confirmed to be still valid on branch mozilla-release  (reproduced on revision 53fc01ba93c2).

Comment 11

[Christian Holler (:decoder)]

Also trying to confirm for ESR17 branch.

Comment 12

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically confirmed to be still valid on branch mozilla-esr17  (reproduced on revision 30b9dd4e9966).

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

Tracking for ESR 17 that will ship with Firefox 18 - can someone please nominate for esr17 approval (assuming this patch lands cleanly there) or prepare an esr17 patch?

Comment 14

[Brian Hackett [Laid off!]]

Comment on attachment 655357 [details] [diff] [review]
patch

[Approval Request Comment]
Fix Landed on Version: 18
Risk to taking this patch (and alternatives if risky): None

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr17/rev/7b48b8242078

Comment 16

[u279076]

Can this be put in testsuite?