Boris Zbarsky [:bzbarsky] Reporter
	Description • 17 years ago

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
FAIL
../../../../_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.

	Jeff Walden [:Waldo]
	Comment 1 • 17 years ago

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.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 2 • 17 years ago

Robert says the tests pass in debug Windows builds.

	Robert Strong (they/them - no direct email)
	Comment 3 • 17 years ago

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.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 4 • 17 years ago

OK.  So what's failing, then?

	Robert Strong (they/them - no direct email)
	Comment 5 • 17 years ago

Bug 181160 and Bug 369558 are the ones that I know of

	Robert Strong (they/them - no direct email)
	Comment 6 • 17 years ago

and Bug 339754

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 7 • 17 years ago

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?

	Jeff Walden [:Waldo]
	Comment 8 • 17 years ago

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.

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 9 • 17 years ago

I assume you read the log attached to this bug?

	Robert Strong (they/them - no direct email)
	Comment 10 • 17 years ago

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.

	Jeff Walden [:Waldo]
	Comment 11 • 17 years ago

(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.

	Robert Strong (they/them - no direct email)
	Comment 12 • 17 years ago

On Windows with venkman the tests pass but I'd still like you to try comment #10. Thanks!

	Dave Townsend [:mossop]
	Comment 13 • 17 years ago

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)

	Dave Townsend [:mossop]
	Comment 14 • 17 years ago

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

	Boris Zbarsky [:bzbarsky] Reporter
	Comment 15 • 17 years ago

> Could you try manually moving the 
> bin/extensions/f13b157f-b174-47e7-a34d-4815ddfdfeb8

Seems to have no effect.

	Dave Townsend [:mossop]
	Comment 16 • 14 years ago

So tests are running on tinderbox on debug builds so I presume that this is no longer an issue.