483857 - JavaScript Debug assertions in gloda mime tests

Status: RESOLVED FIXED

(MailNews Core :: Database, defect)

Description

[Mark Banner (:standard8)]

Attachment: Debug Log

I'm trying to run make check on debug builds, I'm hitting various debug assertions in the gloda tests which means I can't do a successful "make -C mailnews check" run on a debug build. This isn't good for our developers who generally use debug builds afaik, hence the blocker status.

Comment 1

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

The assertion is at:
"/Users/moztest/comm/main/src/mozilla/js/src/jstracer.cpp:3174"

This looks like tracemonkey's problem, not gloda's problem.  I suggest we turn off tracemonkey for xpcshell tests.  (nb: Gloda is using more complex javascript features which likely cause gloda to get hit with the troubles.)

Comment 2

[Mark Banner (:standard8)]

(In reply to comment #1)
> The assertion is at:
> "/Users/moztest/comm/main/src/mozilla/js/src/jstracer.cpp:3174"
> 
> This looks like tracemonkey's problem, not gloda's problem.  I suggest we turn
> off tracemonkey for xpcshell tests.  (nb: Gloda is using more complex
> javascript features which likely cause gloda to get hit with the troubles.)

Well, unless there's some pref I don't know about, the default prefs:

pref("javascript.options.jit.content",      true);
pref("javascript.options.jit.chrome",       false);

will mean tracemonkey isn't enabled for xpcshell tests. Therefore this looks like we're hitting an assertion either with a javascript error or because gloda is doing something wrong.

cc'ing some folks who I hope can help us.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

It turns out that in that particular preference name "content" is s3cr3t c0de for "content and XPCOM components".  Given that we have reproducible tests for these problems, it seems like we'd be better off just filing specific bugs against tracemonkey.

Comment 4

[Jeff Walden [:Waldo]]

Bug 480132 may have fixed that assertion; I suggest retesting with source that includes that fix and see whether it's still there before doing anything else.

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #4)
> Bug 480132 may have fixed that assertion; I suggest retesting with source that
> includes that fix and see whether it's still there before doing anything else.

I've just tried comm-central with today's trunk (head: http://hg.mozilla.org/mozilla-central/rev/e74b36d547de) and there are no problems with the tests, so it does look like it could have been fixed with that bug.

Will bug 480132 be going onto the 1.9.1 branch?

Comment 6

[Jeff Walden [:Waldo]]

Yes.

Comment 7

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

I should have popped into TB JS bugs earlier - "Assertion failure: !(fp->flags & JSFRAME_POP_BLOCKS)" is all too familiar to me a while back.

That assertion has indeed since been fixed. Perhaps resolve this and move on?

Comment 8

[Mark Banner (:standard8)]

(In reply to comment #7)
> I should have popped into TB JS bugs earlier - "Assertion failure: !(fp->flags
> & JSFRAME_POP_BLOCKS)" is all too familiar to me a while back.
> 
> That assertion has indeed since been fixed. Perhaps resolve this and move on?

It has been fixed on trunk, not 1.9.1 branch which is where our main focus is at the moment.

Comment 9

[Mark Banner (:standard8)]

Also I believe this isn't just JIT. I tried setting "javascript.options.jit.content" to false in all.js and still reproduced the error.

So unless that pref doesn't work for xpcshell tests, then this isn't a JIT specific bug afaict.

Comment 10

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

(In reply to comment #9)
> Also I believe this isn't just JIT. I tried setting
> "javascript.options.jit.content" to false in all.js and still reproduced the
> error.
> 
> So unless that pref doesn't work for xpcshell tests, then this isn't a JIT
> specific bug afaict.

Strange - jstracer.cpp usually involves JIT as far as I know, perhaps gal or mrbkap can correct me if I'm wrong?

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #9)
> So unless that pref doesn't work for xpcshell tests, then this isn't a JIT
> specific bug afaict.

It doesn't. xpcshell relies on flags passed to the program (in this case, -j). This is controlled by mozilla/testing/xpcshell/runxpcshelltests.py that passes -j unconditionally.

Comment 12

[David :Bienvenu]

Is this different from bug 485585 ? Is it still happening?

Comment 13

[Ludovic Hirlimann [:Usul]]

(In reply to comment #12)
> Is this different from bug 485585 ? Is it still happening?

David : yes it needs to land on Branch.

Comment 14

[Mark Banner (:standard8)]

Bug 480132 has now landed on 1.9.1. I've just done a successful run through gloda with a debug build, so this bug is now fixed by the landing of bug 480132.