630098 - pluginproblemui-direction-2-ref.html | Exited with code -6 during test run

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[John Daggett (:jtd)]

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

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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)

Comment 2

[Benjamin Smedberg]

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?

Comment 3

[(not currently active) Ted Mielczarek]

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

Comment 4

[(no longer active)]

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

Comment 5

[(not currently active) Ted Mielczarek]

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.

Comment 6

[(no longer active)]

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

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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?

Comment 8

[(not currently active) Ted Mielczarek]

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.

Comment 9

[Ed Morley [:emorley]]

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