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

Status: RESOLVED FIXED

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

Description

[Calixte Denizet (:calixte)]

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

Top 10 frames of crashing thread:

0 libxul.so std::_Function_handler<void> >::_M_invoke dom/media/systemservices/CamerasParent.cpp:892
1 libxul.so mozilla::camera::VideoEngine::WithEntry gcc/include/c++/6.4.0/functional:2127
2 libxul.so mozilla::media::LambdaRunnable<mozilla::camera::CamerasParent::RecvStartCapture> >::Run dom/media/systemservices/CamerasParent.cpp:919
3 libxul.so nsThread::ProcessNextEvent 
4 libxul.so NS_ProcessNextEvent 
5 libxul.so mozilla::ipc::MessagePumpForNonMainThreads::Run 
6 libxul.so MessageLoop::Run 
7 libxul.so base::Thread::ThreadMain ipc/chromium/src/base/thread.cc:181
8 libxul.so ThreadFunc ipc/chromium/src/base/platform_thread_posix.cc:38
9 libpthread-2.26.so libpthread-2.26.so@0x7089 

=============================================================

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.

[1] https://hg.mozilla.org/mozilla-central/rev/d057ff6cbcfb

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

[Tracking Requested - why for this release]: crash

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Sure, I can track this since it's a recent regression in 59. Let me know if you need anything.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Several of the crashes are wildptr's -> sec-high

Comment 4

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

Don't have a clue yet.
I thought we don't use pointer in the crash line.
https://hg.mozilla.org/mozilla-central/annotate/709f355a7a8c/dom/media/systemservices/CamerasParent.cpp#l892

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 6

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

Attachment: bug1419374-check-if-the-iterator-is-valid.patch

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.

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Comment on attachment 8938316 [details] [diff] [review]
bug1419374-check-if-the-iterator-is-valid.patch

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?

Comment 8

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

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.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/530f8947e66c15581c0eac0ad3a39bd8d6856d48

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/530f8947e66c