http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1296441343.1296442486.1911.gz Looks very similar to bug 611033, but occurred on OSX: REFTEST TEST-START | file:///Users/cltbld/talos-slave/test/build/reftest/tests/modules/plugin/test/reftest/pluginproblemui-direction-1.html ###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv WARNING: Failed to send message!: file /builds/slave/cen-osx64-dbg/build/dom/plugins/PluginScriptableObjectParent.cpp, line 219 JavaScript error: file:///Users/cltbld/talos-slave/test/build/reftest/tests/modules/plugin/test/reftest/pluginproblemui-direction-1.html, line 18: Error calling method on NPObject! ###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv ###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv REFTEST TEST-START | file:///Users/cltbld/talos-slave/test/build/reftest/tests/modules/plugin/test/reftest/pluginproblemui-direction-1-ref.html [loaded plugin /private/var/folders/H5/H5TD8hgwEqKq9hgKlayjWU+++TM/-Tmp-/tmpw7JQAz/plugins/Test.plugin] WARNING: NS_ENSURE_TRUE(compMgr) failed: file nsComponentManagerUtils.cpp, line 90 ###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv WARNING: Failed to send message!: file /builds/slave/cen-osx64-dbg/build/dom/plugins/PluginScriptableObjectParent.cpp, line 219 JavaScript error: file:///Users/cltbld/talos-slave/test/build/reftest/tests/modules/plugin/test/reftest/pluginproblemui-direction-1-ref.html, line 18: Error calling method on NPObject! ###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv REFTEST TEST-KNOWN-FAIL(EXPECTED RANDOM) | file:///Users/cltbld/talos-slave/test/build/reftest/tests/modules/plugin/test/reftest/pluginproblemui-direction-1.html | image comparison (==) REFTEST INFO | Loading a blank page REFTEST TEST-START | file:///Users/cltbld/talos-slave/test/build/reftest/tests/modules/plugin/test/reftest/pluginproblemui-direction-2.html WARNING: NS_ENSURE_TRUE(compMgr) failed: file nsComponentManagerUtils.cpp, line 90 ###!!! [Parent][RPCChannel] Error: Channel error: cannot send/recv WARNING: Failed to send message!: file /builds/slave/cen-osx64-dbg/build/dom/plugins/PluginScriptableObjectParent.cpp, line 219 JavaScript error: file:///Users/cltbld/talos-slave/test/build/reftest/tests/modules/plugin/test/reftest/pluginproblemui-direction-2.html, line 22: Error calling method on NPObject! ###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv REFTEST TEST-START | file:///Users/cltbld/talos-slave/test/build/reftest/tests/modules/plugin/test/reftest/pluginproblemui-direction-2-ref.html Assertion failure: 0 == flags, at /builds/slave/cen-osx64-dbg/build/nsprpub/pr/src/pthreads/ptio.c:3332 WARNING: child WaitForMessage() failed: file /builds/slave/cen-osx64-dbg/build/toolkit/xre/nsEmbedFunctions.cpp, line 352 NEXT ERROR TEST-UNEXPECTED-FAIL | file:///Users/cltbld/talos-slave/test/build/reftest/tests/modules/plugin/test/reftest/pluginproblemui-direction-2-ref.html | Exited with code -6 during test run

The key line seems to be: Assertion failure: 0 == flags, at /builds/slave/cen-osx64-dbg/build/nsprpub/pr/src/pthreads/ptio.c:3332 (NSPR assertions are fatal)

Ugh, we're not getting any stack trace from the assertion, which makes it very difficult to figure out what might be failing. Can you reproduce this locally?

Bleh, NSPR uses DebugBreak on Windows (which should now trigger Breakpad), but abort() on other platforms, which definitely doesn't work on OS X: http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/io/prlog.c#566

(In reply to comment #3) > Bleh, NSPR uses DebugBreak on Windows (which should now trigger Breakpad), but > abort() on other platforms, which definitely doesn't work on OS X: > http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/io/prlog.c#566 Is there an equivalent call for other platforms?

I don't know of an easy way to do this on Mac, offhand. Our mozalloc_abort just intentionally crashes: http://mxr.mozilla.org/mozilla-central/source/memory/mozalloc/mozalloc_abort.cpp#60 abort() probably works on Linux, since we can catch SIGABRT, but on Mac it doesn't trip the Mach exception handler.

(In reply to comment #5) > I don't know of an easy way to do this on Mac, offhand. Our mozalloc_abort just > intentionally crashes: > http://mxr.mozilla.org/mozilla-central/source/memory/mozalloc/mozalloc_abort.cpp#60 > > abort() probably works on Linux, since we can catch SIGABRT, but on Mac it > doesn't trip the Mach exception handler. So, should we get a new bug on fixing NSPR to crash intentionally instead of calling abort?

For application/x-test found plugin Test.plugin Assertion failure: 0 == flags, at /builds/slave/cen-osx64-dbg/build/nsprpub/pr/src/pthreads/ptio.c:3332 WARNING: child WaitForMessage() failed: file /builds/slave/cen-osx64-dbg/build/toolkit/xre/nsEmbedFunctions.cpp, line 352 From that log snippet, I would guess the error is originating at 2519 nsPluginHost::WritePluginInfo() ... 2549 rv = localFile->OpenNSPRFileDesc(PR_WRONLY | PR_CREATE_FILE | PR_TRUNCATE, 0600, &fd); ... but it's a wild guess. I don't see anything wrong with OpenNSPRFileDesc() on down into NSPR that might cause this. Sure looks like a bad one, hope we can repro eventually. (In reply to comment #5) > abort() probably works on Linux, since we can catch SIGABRT, but on Mac it > doesn't trip the Mach exception handler. Would it be possible to install signal handlers on mac that just immediately trigger the Mach handler?

I don't know of any way to trigger the Mach handler except for actually crashing, but maybe. I also don't know what that interaction would look like if you have both a signal handler and a Mach exception handler installed. Who gets to catch it first? I guess maybe if you only handle SIGABRT it might work? We could try that.

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