Closed Bug 1419374 Opened 3 years ago Closed 3 years ago

Crash in std::_Function_handler<T>::_M_invoke


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

59 Branch



Tracking Status
firefox-esr52 --- unaffected
firefox57 --- unaffected
firefox58 --- unaffected
firefox59 + fixed


(Reporter: calixte, Assigned: mchiang)


(Blocks 1 open bug)


(4 keywords, Whiteboard: [clouseau])

Crash Data


(1 file)

This bug was filed from the Socorro interface and is
report bp-4e4f14c1-ec71-4d4b-9cb7-73c370171120.

Top 10 frames of crashing thread:

0 std::_Function_handler&lt;void&gt; &gt;::_M_invoke dom/media/systemservices/CamerasParent.cpp:892
1 mozilla::camera::VideoEngine::WithEntry gcc/include/c++/6.4.0/functional:2127
2 mozilla::media::LambdaRunnable&lt;mozilla::camera::CamerasParent::RecvStartCapture&gt; &gt;::Run dom/media/systemservices/CamerasParent.cpp:919
3 nsThread::ProcessNextEvent 
4 NS_ProcessNextEvent 
5 mozilla::ipc::MessagePumpForNonMainThreads::Run 
6 MessageLoop::Run 
7 base::Thread::ThreadMain ipc/chromium/src/base/
8 ThreadFunc ipc/chromium/src/base/


There are 2 crashes in nightly 59 with buildid 20171119100329. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1388667.

Flags: needinfo?(mchiang)
Assignee: nobody → mchiang
Flags: needinfo?(mchiang)
[Tracking Requested - why for this release]: crash
Rank: 10
Priority: -- → P2
Sure, I can track this since it's a recent regression in 59. Let me know if you need anything.
Several of the crashes are wildptr's -> sec-high
Group: media-core-security
Rank: 10 → 5
Flags: needinfo?(mchiang)
Priority: P2 → P1
Flags: needinfo?(mchiang)
(In reply to Munro Mengjue Chiang [:mchiang] from comment #4)
> Don't have a clue yet.
> I thought we don't use pointer in the crash line.

Maybe not directly, but indirectly for vtbl and/or the iterator, etc.
MOZ_ASSERT doesn't scream in Nightly.
And here we didn't check if iterator is valid before using it.
So I add a check here.
I also replace MOZ_ASSERT with MOZ_DIAGNOSTIC_ASSERT to confirm we were indeed hit by this problem.
After confirming it, I will change back to MOZ_ASSERT.
Attachment #8938316 - Flags: review?(jib)
Comment on attachment 8938316 [details] [diff] [review]

Review of attachment 8938316 [details] [diff] [review]:

Change lgtm as an improvement.

But can you tell me more about this invariant, and how it's broken? It sounds like we haven't gotten to the bottom of the issue.

E.g. is this a case of a camera with zero capabilities? Something else? A race?
Attachment #8938316 - Flags: review?(jib) → review+
The chance we hit a race condition is low because we only access mAllCandidateCapabilities in videocapture thread, and we use self to hold the camerasparent so it cannot be destroyed. Probably we hit the case candidateCapabilities->second.size() == 0. Maybe the (dummy) hardware is very special and it returns zero supported capacity. That's what we gonna find out with the MOZ_DIAGNOSTIC_ASSERT.
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Group: media-core-security → core-security-release
Group: core-security-release
Depends on: 1435670
You need to log in before you can comment on or make changes to this bug.