Closed Bug 803093 Opened 12 years ago Closed 12 years ago

Lack of locking in access to MediaEngineWebRTC singleton

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla19
Tracking Status
firefox18 --- unaffected
firefox19 --- fixed
firefox-esr10 --- unaffected
firefox-esr17 --- unaffected

People

(Reporter: jesup, Assigned: jesup)

References

Details

(Keywords: sec-low, Whiteboard: [qa-][adv-main19-])

Attachments

(1 file)

-585353472[7f9cfe5c06a0]: ###!!! ASSERTION: op == PL_DHASH_LOOKUP || RECURSION_LEVEL(table) == 0: 'op == PL_DHASH_LOOKUP || RECURSION_LEVEL(table) == 0', file pldhash.cpp, line 574
###!!! ASSERTION: op == PL_DHASH_LOOKUP || RECURSION_LEVEL(table) == 0: 'op == PL_DHASH_LOOKUP || RECURSION_LEVEL(table) == 0', file pldhash.cpp, line 574


The backtrace for those is:
#0  NS_DebugBreak_P (aSeverity=1, aStr=0x7ffff50181cb "RECURSION_LEVEL(table_) > 0", aExpr=
    0x7ffff50181b0 "RECURSION_LEVEL(table) > 0", aFile=0x7ffff501811a "pldhash.cpp", aLine=669)
    at ../../../xpcom/base/nsDebugImpl.cpp:286
#1  0x00007ffff390bed0 in PL_DHashTableOperate (table=0x7fffde156d50, key=0x7fff5bb36a00, op=
    PL_DHASH_LOOKUP) at pldhash.cpp:669
#2  0x00007ffff2da0ef3 in nsTHashtable<nsBaseHashtableET<nsStringHashKey, nsRefPtr<mozilla::MediaEngineWebRTCAudioSource> > >::GetEntry (this=0x7fffde156d50, aKey=...)
    at ../../../dist/include/nsTHashtable.h:148
#3  0x00007ffff2da0a27 in nsRefPtrHashtable<nsStringHashKey, mozilla::MediaEngineWebRTCAudioSource>::Get (this=0x7fffde156d50, aKey=..., pRefPtr=0x7fff5bb36ba0)
    at ../../../dist/include/nsRefPtrHashtable.h:83
#4  0x00007ffff2da05ff in mozilla::MediaEngineWebRTC::EnumerateAudioDevices (this=0x7fffde156d00, 
    aASources=0x7fff5bb36c30) at ../../../../content/media/webrtc/MediaEngineWebRTC.cpp:165
#5  0x00007ffff2aaa76d in mozilla::GetUserMediaDevicesRunnable::Run (this=0x7fffdee98130)
    at ../../../dom/media/MediaManager.cpp:623
#6  0x00007ffff397a408 in nsThread::ProcessNextEvent (this=0x7fffba2ed7a0, mayWait=true, result=
    0x7fff5bb36def) at ../../../xpcom/threads/nsThread.cpp:612
#7  0x00007ffff3909b6e in NS_ProcessNextEvent_P (thread=0x7fffba2ed7a0, mayWait=true)
    at nsThreadUtils.cpp:220
#8  0x00007ffff39792ce in nsThread::ThreadFunc (arg=0x7fffba2ed7a0)
    at ../../../xpcom/threads/nsThread.cpp:256
#9  0x00007ffff7ae70c9 in _pt_root (arg=0x7fffba2e4020)
    at ../../../../../nsprpub/pr/src/pthreads/ptthread.c:156
#10 0x0000003151a07b41 in start_thread (arg=0x7fff5bb37700) at pthread_create.c:305
#11 0x00000031516e0e6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

This appears to be a lack of locking for access to EnumerateAudioDevices/EnumerateVideoDevices when bug 802411 landed.
Comment on attachment 672785 [details] [diff] [review]
Lock access to MediaEngineWebRTC singleton

I seem unable to cause the failure now.
Attachment #672785 - Flags: review?(anant)
The more I think about it, this may be the actual cause of Jesse's failures.  Marking as security until we're sure, though I can't get it to crash or do anything but throw assertions.
Blocks: 802982
Group: core-security
Comment on attachment 672785 [details] [diff] [review]
Lock access to MediaEngineWebRTC singleton

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

Nice catch!
Attachment #672785 - Flags: review?(anant) → review+
https://hg.mozilla.org/mozilla-central/rev/f1bdc236456d
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [qa-]
Whiteboard: [qa-] → [qa-][adv-main19-]
Group: core-security
Keywords: sec-low
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: