Closed Bug 602345 Opened 14 years ago Closed 12 years ago

test_jetpack.js | test failed (with xpcshell return code: -6), with "Assertion failure: 0 == rv, at ptsynch.c:372"

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: dholbert, Unassigned)

References

Details

(Keywords: intermittent-failure) 

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1286400719.1286402180.8984.gz
Rev3 MacOSX Leopard 10.5.8 mozilla-central debug test xpcshell on 2010/10/06 14:31:59
s: talos-r3-leopard-016
{
TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard-old-debug_test-xpcshell/build/xpcshell/tests/js/jetpack/tests/unit/test_jetpack.js | test failed (with xpcshell return code: -6), see following log:
  >>>>>>>
  ### XPCOM_MEM_LEAK_LOG defined -- logging leaks to /var/folders/Xr/Xr--yJnSEY0U11ET5NZuMU+++TM/-Tmp-/tmpgnzVhU/runxpcshelltests_leaks.log
pldhash: for the table at address 0x44d4b8, the given entrySize of 48 probably favors chaining over double hashing.
nsNativeModuleLoader::LoadModule("/Users/cltbld/talos-slave/mozilla-central_leopard-old-debug_test-xpcshell/build/MinefieldDebug.app/Contents/MacOS/components/libxpcomsample.dylib") - load FAILED, rv: 80004005, error:
	Unknown error: -2804
}
I see the libxpcomsample error all the time when running xpcshell tests on mac, but the tests don't appear to fail due to it.  I suspect it's not important to this log.
Ok, thanks for the heads up.  Should I retarget this to Mozilla Labs | Jetpack Prototype then?  (That's the component where this test was created... but the last two modifications to the test have been in Core|XPCOM bugs, so maybe Core|XPCOM owns the test now?)
OS: Linux → Mac OS X
Hardware: x86_64 → x86
aha! The end of the "See following log" chunk has this:
{
TEST-PASS | (xpcshell/head.js) | 75 (+ 0) check(s) passed
NOTE: child process received `Goodbye', closing down
WARNING: nsExceptionService ignoring thread destruction after shutdown: file /builds/slave/mozilla-central-macosx-debug/build/xpcom/base/nsExceptionService.cpp, line 197
nsStringStats
 => mAllocCount:            122
 => mReallocCount:            0
 => mFreeCount:             122
 => mShareCount:            129
 => mAdoptCount:              0
 => mAdoptFreeCount:          0
Assertion failure: 0 == rv, at /builds/slave/mozilla-central-macosx-debug/build/nsprpub/pr/src/pthreads/ptsynch.c:372
}
I'm guessing that assertion-failure is what's being considered a failure here.

So maybe this is a rarely-seen NSPR bug?
Might be the same as / related to bug 463594 (which is also about a "0 == rv" abort in ptsynch.c, but on a different line, but maybe it's really the same line since that bug is from 2008)...
Summary: test_jetpack.js | test failed (with xpcshell return code: -6), with this about libxpcomsample.dylib: "load FAILED, rv: 80004005, error: Unknown error: -2804" → test_jetpack.js | test failed (with xpcshell return code: -6), with "Assertion failure: 0 == rv, at ptsynch.c:372"
Yes, the assertion failure is the problem (NSPR asserts are fatal). It sucks that we don't have a stack for the assertion.

We don't have a stack because this is mac, and mac doesn't trigger breakpad with abort(): http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/io/prlog.c#551

I wonder if we can change PR_Assert to be more crashy and less abort()y, copying the logic from http://mxr.mozilla.org/mozilla-central/source/memory/mozalloc/mozalloc_abort.cpp#69

Has this appeared on non-mac at all?
(In reply to comment #5)
> Has this appeared on non-mac at all?

Not that I know of -- the Mac log from comment 0 is the first I've seen this assertion-failure, and the only other bug to mention this assertion in its summary (bug 463594) also only has failures on Mac.
Mass marking whiteboard:[orange] bugs WFM (to clean up TBPL bug suggestions) that:
* Haven't changed in > 6months
* Whose whiteboard contains none of the strings: {disabled,marked,random,fuzzy,todo,fails,failing,annotated,leave open,time-bomb}
* Passed a (quick) manual inspection of bug summary/whiteboard to ensure they weren't a false positive.

I've also gone through and searched for cases where the whiteboard wasn't labelled correctly after test disabling, by using attachment description & basic comment searches. However if the test for which this bug was about has in fact been disabled/annotated/..., please accept my apologies & reopen/mark the whiteboard appropriately so this doesn't get re-closed in the future (and please ping me via IRC or email so I can try to tweak the saved searches to avoid more edge cases).

Sorry for the spam! Filter on: #FFA500
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.