796906 - ASSERTION: Don't call on main thread: '!NS_IsMainThread()', file /alder/dom/media/MediaManager.cpp, line 323

Status: VERIFIED WORKSFORME

(Core :: WebRTC, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20121002142130

By applying the not yet checked-in Mochitest from bug 795367 (attachment 666256 [details] [diff] [review]) I get a couple of assertions with a debug build. All of them are of this kind:

###!!! ASSERTION: Don't call on main thread: '!NS_IsMainThread()', file /Volumes/data/code/firefox/alder/dom/media/MediaManager.cpp, line 323
mozilla::GetUserMediaRunnable::Run()+0x0000004E [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/XUL +0x012154DE]
nsThread::ProcessNextEvent(bool, bool*)+0x00000653 [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/XUL +0x02704583]
NS_ProcessPendingEvents_P(nsIThread*, unsigned int)+0x0000009D [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/XUL +0x0266940D]
nsBaseAppShell::NativeEventCallback()+0x000000D1 [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/XUL +0x020A5E11]
nsAppShell::ProcessGeckoEvents(void*)+0x000001C2 [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/XUL +0x02036FB2]
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__+0x00000011 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x000124F1]
__CFRunLoopDoSources0+0x000000FD [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x00011D5D]
__CFRunLoopRun+0x00000389 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x00038B49]
CFRunLoopRunSpecific+0x000000E6 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x00038486]
RunCurrentEventLoopInMode+0x00000115 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x000022BF]
ReceiveNextEventCommon+0x000000B5 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x000094BF]
BlockUntilNextEventMatchingListInMode+0x0000003E [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x000093FA]
_DPSNextEvent+0x00000293 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00008779]
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x00000087 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x0000807D]
-[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x00000077 [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/XUL +0x020355D7]
-[NSApplication run]+0x000001D6 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x000049B9]
nsAppShell::Run()+0x0000008C [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/XUL +0x02037ABC]
nsAppStartup::Run()+0x00000097 [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01C79BC7]
XREMain::XRE_mainRun()+0x00001873 [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/XUL +0x00014943]
XREMain::XRE_main(int, char**, nsXREAppData const*)+0x00000304 [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/XUL +0x00015154]
XRE_main+0x00000046 [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/XUL +0x00015606]
_ZL7do_mainiPPc+0x00000380 [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/firefox-bin +0x00001D20]
main+0x000002AD [/Volumes/data/code/firefox/obj/alder/dist/NightlyDebug.app/Contents/MacOS/firefox-bin +0x000015ED]

This is just a raw dump. I will make sure to attach a processed and cleaned-up stack. But as the stack shows it's clearly a fault of the gum code.

Does it have to block Firefox 18.0?

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The command to run after applying the patch is:

TEST_PATH=dom/tests/mochitest/media/ make -C $(OBJ_DIR) mochitest-plain

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: testcase

Simplified testcase to reproduce the assertion. Just load it in an Alder build.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Fixed assertion stack:

###!!! ASSERTION: Don't call on main thread: '!NS_IsMainThread()', file dom/media/MediaManager.cpp, line 323
ozilla::GetUserMediaRunnable::Run() (MediaManager.cpp:325, in XUL)
nsThread::ProcessNextEvent(bool, bool*) (in XUL) (nsThread.cpp:613)
NS_ProcessPendingEvents_P(nsIThread*, unsigned int) (in XUL) (nsThreadUtils.cpp:170)
sBaseAppShell::NativeEventCallback() (nsBaseAppShell.cpp:98, in XUL)
sAppShell::ProcessGeckoEvents(void*) (nsAppShell.mm:402, in XUL)
CFNumberGetValue (in CoreFoundation) + 737
CFSetApplyFunction (in CoreFoundation) + 13
__CFBinaryPlistCreateObject2 (in CoreFoundation) + 3801
__CFBinaryPlistCreateObject2 (in CoreFoundation) + 2070
AcquireEventFromQueue (in HIToolbox) + 481
GestureHandlerStatusChanged (in HIToolbox) + 223
GetEventClassRef (in HIToolbox) + 18
-[NSDocumentController(NSCompatibility) _types] (in AppKit) + 167
--[NSDocumentController(NSInternal) _installOpenRecentMenus] (in AppKit) + 1218
--[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in XUL) (nsAppShell.mm:168)
-_NXIsActiveApp (in AppKit) + 97
sAppShell::Run() (nsAppShell.mm:756, in XUL)
sAppStartup::Run() (nsAppStartup.cpp:290, in XUL)
REMain::XRE_mainRun() (nsAppRunner.cpp:3782, in XUL)
XREMain::XRE_main(int, char**, nsXREAppData const*) (in XUL) (nsAppRunner.cpp:3848)
RE_main (nsAppRunner.cpp:3923, in XUL)
ZL7do_mainiPPc (nsBrowserApp.cpp:174, in firefox-bin)
ain (nsBrowserApp.cpp:279, in firefox-bin)

Comment 4

[Jason Smith [:jsmith]]

Looks like this is a gUM bug.

Comment 5

[Anant Narayanan [:anant]]

I can't reproduce this on the latest nightly.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Could this have been fixed with bug 798829? I will update my local code and test again.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Anant Narayanan [:anant] from comment #5)
> I can't reproduce this on the latest nightly.

Closing per Anant's comment. Reopen if someone can reproduce.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I can't find when it has been fixed. So lets call it WFM.