563764 - jit not working correctly in chrome for Thunderbird trunk builds

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Mark Banner (:standard8)]

We recently landed a patch which changed how our quick search filters to Thunderbird. As a result of the patch, we got issues on trunk but 3.1 branch (= Gecko 1.9.2) is fine with the same Thunderbird changes. This was reflected in our mozmill test results as well.

It turns out that setting "javascript.options.jit.chrome" to false, fixes the failures.

This strongly points to an issue with the javascript engine.

As mentioned in bug 561321, one error seen with a debug build was:

WARNING: leaking reference to nsTimerImpl: file
/Volumes/Developer/temp/src/mozilla/xpcom/threads/nsTimerImpl.cpp, line 493
--DOMWINDOW == 16 (0x2f193fa0) [serial = 11] [outer = 0x2e9f8040] [url =
about:blank]
WARNING: NS_ENSURE_TRUE(thread) failed: file
/Volumes/Developer/temp/src/mozilla/netwerk/base/src/nsSocketTransportService2.cpp,
line 121
-- Exception object --
+ message (string) 'domNode is not defined'
+ fileName (string) 'chrome://messenger/content/quickFilterBar.js'
+ lineNumber (number) 194
+ stack (string) '([object
XULCommandEvent])@chrome://messenger/content/quickFilterBar.js:194
'
+ name (string) 'ReferenceError'
*
-- Stack Trace --
([object XULCommandEvent])@chrome://messenger/content/quickFilterBar.js:194

There's a similar error for our mozmill tests on our tinderboxes:

http://tinderbox.mozilla.org/showlog.cgi?tree=Thunderbird&errorparser=unittest&logfile=1272995539.1273000481.7767.gz&buildtime=1272995539&buildname=MacOSX%2010.5%20comm-central%20check&fulltext=1

The relevant code is around here:

http://hg.mozilla.org/comm-central/annotate/058e1555a691/mail/base/content/quickFilterBar.js#l185

I'm a bit wary of the comment that asuth makes there about 1.9.2, but if I'm reading the code right, I don't think that affects us here.


As we've got our heads-down on releasing Thunderbird 3.1, we're going to be turning off jit.chrome on our trunk builds, because they are permanently orange at the moment, though we'll need this resolving for the next version of Thunderbird (of course).

The fact we're heads down on 3.1 may affect our responsiveness, but we thought we'd better file this anyway so that you guys know about it.

Comment 1

[Mark Banner (:standard8)]

Andrew, do you have time to look into this now we're slightly less active on 3.1?

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Unless the problem is moot at this point, I expect this is a pretty deep rabbit hole; I won't have that much free time until at least the end of next week.

The 1.9.2 comment was because I thought brendan had made a comment in the past about changing the spec so that closed-over loop-defined iteration variables latch to conform with expectations... for all I know the latching let is gratuitous in 1.9.3.

Comment 3

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

jorendorff mentions over IRC that something like this was fixed recently, so it'll be interesting to note whether it still occurs.

Comment 4

[Mark Banner (:standard8)]

(In reply to comment #3)
> jorendorff mentions over IRC that something like this was fixed recently, so
> it'll be interesting to note whether it still occurs.

I've just pushed a patch to our try server to build with latest mozilla-central. Now it does mozmill tests we should easily be able to see if this is resolved or not.

Comment 5

[Nomis101]

I was also interested three days ago to see if this incidentaly was fixed already, so I've set jit.chrome back to true. But with jit.chrome to true, filtering with quickfilter bar doesn't work anymore (tested with attachments filter), so it seems to me its not fixed.
I've tested this once again today with a current trunk build (own build with latest m-c), same there.

Comment 6

[Wayne Mery (:wsmwk)]

(reverse session restore monkey business again)

Comment 7

[Mark Banner (:standard8)]

Just to confirm try server did show that this was still happening:

http://tinderbox.mozilla.org/showlog.cgi?log=ThunderbirdTry/1282068363.1282069615.5457.gz#err0
http://tinderbox.mozilla.org/showlog.cgi?log=ThunderbirdTry/1282063860.1282064339.13477.gz

(and its across all platforms)

Comment 8

[Jason Orendorff [:jorendorff]]

OK. "Fixed recently" in comment 3 means yesterday; see bug 583757. Do you have either changeset 7802c6c281e2 or changeset 870371756071 in your mozilla repo?

Comment 9

[Mark Banner (:standard8)]

The logs indicate mozilla-central revision 5ca9e053ee98, which would mean the first of those revisions was included:

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-08-16+22%3A52&enddate=2010-08-17+07%3A40

Comment 10

[Jason Orendorff [:jorendorff]]

Thanks. Is there any chance you could extract a chrome mochitest or something from this, just to get the "minimized test case" ball rolling?

Comment 11

[Mark Banner (:standard8)]

I've just been testing with the latest tracemonkey code on various platforms and servers, and it appears this is fixed (ftr I was using changeset a1f43f4ef565).

So hopefully this will be fixed with the next merge to mozilla-central.

Comment 12

[Nomis101]

I'm also seeing this. If I build a TB version with the current tracemonkey tip, than I can set jit.chrome (and methodjit.chrom) to true and the quickfilter bar still works correctly (tested with all filter options). :-)

Comment 13

[Nomis101]

Because JM is now in m-c I don't see this issue anymore in the newest nightly build, so seems fixed. Can anyone confirm this?

Comment 14

[Mark Banner (:standard8)]

I've now backed out the previous disabling of the jit in chrome, and this is all still working the same.

http://hg.mozilla.org/comm-central/rev/b8ae09466dca

We don't know what fixed it, but at least its fixed.