Closed Bug 1419374 Opened 2 years ago Closed 2 years ago
Crash in std::_Function
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  to fix bug 1388667.  https://hg.mozilla.org/mozilla-central/rev/d057ff6cbcfb
Assignee: nobody → mchiang
[Tracking Requested - why for this release]: crash
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
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
(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] 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?
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.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.