Closed Bug 980744 Opened 10 years ago Closed 10 years ago

[B2G getUserMedia] Browser crashes when calling getUserMedia in debug version

Categories

(Core :: WebRTC: Audio/Video, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla31

People

(Reporter: slee, Assigned: slee)

References

Details

Attachments

(1 file, 1 obsolete file)

STR:
* build gecko with debug
* go to http://mozilla.github.io/webrtc-landing/gum_test.html
* choose video and grant the permission

Here is the back trace
#0  __libc_android_abort () at bionic/libc/unistd/abort.c:82
#1  0x42d4e04c in PR_Assert (
    s=0x42e36388 "mon->entryCount != 0 && pthread_equal(mon->owner, pthread_self())", 
    file=0x42e361b0 "/Volumes/ssd/mozilla-central/nsprpub/pr/src/pthreads/ptsynch.c", ln=577)
    at /Volumes/ssd/mozilla-central/nsprpub/pr/src/io/prlog.c:554
#2  0x42d5b72c in PR_AssertCurrentThreadInMonitor (mon=0x44dafc40)
    at /Volumes/ssd/mozilla-central/nsprpub/pr/src/pthreads/ptsynch.c:576
#3  0x42d5b772 in pt_PostNotifyToMonitor (mon=0x44dafc40, broadcast=0)
    at /Volumes/ssd/mozilla-central/nsprpub/pr/src/pthreads/ptsynch.c:443
#4  0x42d5b7bc in PR_Notify (mon=0xdeadbaad)
    at /Volumes/ssd/mozilla-central/nsprpub/pr/src/pthreads/ptsynch.c:721
#5  0x413e6b0c in mozilla::ReentrantMonitor::Notify (this=0x44449f80)
    at ../../../dist/include/mozilla/ReentrantMonitor.h:107
#6  mozilla::MediaEngineWebRTCVideoSource::AllocImpl (this=0x44449f80)
    at /Volumes/ssd/mozilla-central/content/media/webrtc/MediaEngineWebRTCVideo.cpp:519
#7  0x40a492b0 in mozilla::runnable_args_m_0<CSF::VcmSIPCCBinding*, void (sigslot::has_slots<sigslot::single_threaded>::*)()>::Run (this=<value optimized out>)
    at /Volumes/ssd/mozilla-central/media/webrtc/signaling/../../../media/mtransport/runnable_utils_generated.h:49
#8  0x40714728 in nsThread::ProcessNextEvent (this=0x40322780, mayWait=true, result=0xbef11df7)
    at /Volumes/ssd/mozilla-central/xpcom/threads/nsThread.cpp:643
#9  0x406c5668 in NS_ProcessNextEvent (thread=0x40322780, mayWait=true)
    at /Volumes/ssd/mozilla-central/xpcom/glue/nsThreadUtils.cpp:263
#10 0x408d8df2 in mozilla::ipc::MessagePump::Run (this=0x40301b20, aDelegate=0xbef128b4)
    at /Volumes/ssd/mozilla-central/ipc/glue/MessagePump.cpp:136
#11 0x408d8f1a in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x40301b20, 
    aDelegate=0xbef128b4) at /Volumes/ssd/mozilla-central/ipc/glue/MessagePump.cpp:283
#12 0x408c472e in MessageLoop::RunInternal (this=0xbef128b4)
    at /Volumes/ssd/mozilla-central/ipc/chromium/src/base/message_loop.cc:226
#13 0x408c4746 in MessageLoop::RunHandler (this=0xbef128b4)
    at /Volumes/ssd/mozilla-central/ipc/chromium/src/base/message_loop.cc:219
#14 MessageLoop::Run (this=0xbef128b4)
    at /Volumes/ssd/mozilla-central/ipc/chromium/src/base/message_loop.cc:193
#15 0x40eec4ba in nsBaseAppShell::Run (this=0x44251340)
    at /Volumes/ssd/mozilla-central/widget/xpwidgets/nsBaseAppShell.cpp:164
#16 0x418b62fa in XRE_RunAppShell ()
    at /Volumes/ssd/mozilla-central/toolkit/xre/nsEmbedFunctions.cpp:679
#17 0x408d8f26 in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x40301b20, 
    aDelegate=0xbef128b4) at /Volumes/ssd/mozilla-central/ipc/glue/MessagePump.cpp:253
#18 0x408c472e in MessageLoop::RunInternal (this=0xbef128b4)
    at /Volumes/ssd/mozilla-central/ipc/chromium/src/base/message_loop.cc:226
#19 0x408c4746 in MessageLoop::RunHandler (this=0xbef128b4)
    at /Volumes/ssd/mozilla-central/ipc/chromium/src/base/message_loop.cc:219
#20 MessageLoop::Run (this=0xbef128b4)
    at /Volumes/ssd/mozilla-central/ipc/chromium/src/base/message_loop.cc:193
#21 0x418b6b7a in XRE_InitChildProcess (aArgc=2, aArgv=0xbef129c4, aProcess=3203476052)
    at /Volumes/ssd/mozilla-central/toolkit/xre/nsEmbedFunctions.cpp:516
#22 0x00008894 in main (argc=6, argv=0xbef12a54)
    at /Volumes/ssd/mozilla-central/ipc/app/MozillaRuntimeMain.cpp:149
Attached patch patch (obsolete) — Splinter Review
It fixed the assertion fail problem in comment 1. After applying this patch, there is another assertion fail, http://dxr.mozilla.org/mozilla-central/source/content/media/webrtc/MediaEngineWebRTCVideo.cpp#623. GetCurrentScreenConfiguration cannot be called on non-mainthread. I will find other place to call it.
I'd like to see the comments in MediaEngineWebRTC.h updated; in one place it says (for B2G) that mCallbackMonitor is used for mState and mLastCapture, but in other places it says mState is protected by mMonitor - those should be updated to indicate that applies to non-B2G.

Mike, you should look in on this bug as well.

Moving to WebRTC
Component: Video/Audio → WebRTC: Audio/Video
Flags: needinfo?(mhabicher)
Sorry about the missing monitor entry. As for the off-Main Thread callbacks, except for OnNewPreviewFrame(), all of these dispatch runnables to the Main Thread for the DOM-facing CameraControl API, e.g.:

http://dxr.mozilla.org/mozilla-central/source/dom/camera/DOMCameraControlListener.cpp#64

So you won't have any trouble doing something like that.
Flags: needinfo?(mhabicher)
In this patch, I update the comments, remove unnecessary mutex and use mCallbackMonitor to protect mState.
Attachment #8390373 - Flags: review?(rjesup)
Attachment #8390373 - Flags: review?(mhabicher)
Attachment #8390373 - Flags: review?(rjesup) → review+
Assignee: nobody → slee
Comment on attachment 8390373 [details] [diff] [review]
Fix resource that is protected by wrong mutex

Review of attachment 8390373 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the lag--this looks fine to me.
Attachment #8390373 - Flags: review?(mhabicher) → review+
Here is the try server log, https://tbpl.mozilla.org/?tree=Try&rev=f180639f9d85.
Keywords: checkin-needed
Attachment #8387500 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/d2a01804dd2d
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: