Extension manager tests fail in Linux debug builds




Add-ons Manager
11 years ago
8 years ago


(Reporter: bz, Unassigned)



Firefox Tracking Flags

(Not tracked)



(2 attachments)

Created attachment 281593 [details]
The log

I'll put the interesting parts in the comment and attach the full log.  This is a build basically without local changes in it.

mozilla% make -C ../obj-firefox/toolkit/mozapps/extensions/test/ check

../../../../_tests/xpcshell-simple/test_extensionmanager/unit/test_bug299716_2.js: ../../../../../mozilla/tools/test-harness/xpcshell-simple/test_all.sh: line 111: 19067 Aborted                 (core dumped) NATIVE_TOPSRCDIR="$native_topsrcdir" TOPSRCDIR="$topsrcdir" $xpcshell -s $headfiles -f $t $tailfiles 2>$t.log 1>&2
../../../../_tests/xpcshell-simple/test_extensionmanager/unit/test_bug299716.js: FAIL
../../../../_tests/xpcshell-simple/test_extensionmanager/unit/test_bug378216.js: FAIL
../../../../_tests/xpcshell-simple/test_extensionmanager/unit/test_bug394300.js: FAIL

I would expect that most of these are due to the assertions I see, since I seem to recall asserts triggering failure in unit tests.
Only in debug builds, of course, so tinderbox won't fail; I'm surprised people aren't writing these tests in debug builds (I thought most people doing active development used debug builds), because that's the only way I can see that they'd not have known about the failures.
Robert says the tests pass in debug Windows builds.
Just refreshed my memory and the assertions (thread safety iirc) in question have been long standing and are known. That particular test sets env.set("XPCOM_DEBUG_BREAK", "stack"); to workaround it until the thread safety assertions can be worked out.
OK.  So what's failing, then?
No, I mean if the env var is set, then why is the test failing when I run it?  Is it something other than the asserts?  Am I running it wrong?
Is the assert happening before the environment variable's set?  Also, what's the assert?  See $OBJDIR/_tests/xpcshell-simple/test_extensionmanager/unit/*.js.log.
I assume you read the log attached to this bug?
I'm not positive but it could be something to do with venkman. Could you try manually moving the bin/extensions/f13b157f-b174-47e7-a34d-4815ddfdfeb8 directory to somewhere else other than your extensions directory and try again? I'll try building venkman to see if it is the cause.
(In reply to comment #9)
> I assume you read the log attached to this bug?

Clearly not, nor do I remember seeing the attachment in that comment.  I fail at life.
On Windows with venkman the tests pass but I'd still like you to try comment #10. Thanks!
Actually test_bug299716_2 does not disable assertion checking as it should not need to, test_bug299716 does that because it performs an install using xpinstall which is the source of the thread safety assertions (from the bugs in comments 5 and 6)
Created attachment 281643 [details]
test_bug378216 mac assertions

I've run a full check on mac and I'm hitting one of the EM unit tests failing from an assertion, test_bug378216. Full log attached but here is the gist of it:

*** PASS ***
2007-09-20 13:20:36.648 xpcshell[27169]: DebugAssert: Third Party Client: result == 0  [-47 = fBsyErr] FSDeleteContainerContents [/Users/dave/mozilla/source/HEAD/mozilla/xpcom/MoreFiles/MoreFilesX.c:1580]
WARNING: nsExceptionService ignoring thread destruction after shutdown: file /Users/dave/mozilla/source/HEAD/mozilla/xpcom/base/nsExceptionService.cpp, line 191
###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' property!

This is pretty much always bad. It usually means that native code is
making a callback to an interface implemented in JavaScript, but the
document where the JS object was created has already been cleared and the
global properties of that document's window are *gone*. Generally this
indicates a problem that should be addressed in the design and use of the
callback code.
: 'Error', file /Users/dave/mozilla/source/HEAD/mozilla/js/src/xpconnect/src/xpcwrappednativescope.cpp, line 657
> Could you try manually moving the 
> bin/extensions/f13b157f-b174-47e7-a34d-4815ddfdfeb8

Seems to have no effect.


10 years ago
Product: Firefox → Toolkit
So tests are running on tinderbox on debug builds so I presume that this is no longer an issue.
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.