Closed
Bug 396839
Opened 17 years ago
Closed 15 years ago
Extension manager tests fail in Linux debug builds
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bzbarsky, Unassigned)
Details
Attachments
(2 files)
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.
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.
Reporter | ||
Comment 2•17 years ago
|
||
Robert says the tests pass in debug Windows builds.
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.
Reporter | ||
Comment 4•17 years ago
|
||
OK. So what's failing, then?
Comment 5•17 years ago
|
||
Bug 181160 and Bug 369558 are the ones that I know of
Comment 6•17 years ago
|
||
and Bug 339754
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?
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.
Reporter | ||
Comment 9•17 years ago
|
||
I assume you read the log attached to this bug?
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.
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.
Comment 12•17 years ago
|
||
On Windows with venkman the tests pass but I'd still like you to try comment #10. Thanks!
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)
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
Reporter | ||
Comment 15•17 years ago
|
||
> Could you try manually moving the
> bin/extensions/f13b157f-b174-47e7-a34d-4815ddfdfeb8
Seems to have no effect.
Assignee | ||
Updated•16 years ago
|
Product: Firefox → Toolkit
Comment 16•15 years ago
|
||
So tests are running on tinderbox on debug builds so I presume that this is no longer an issue.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•