Crash in [@ AsyncShutdownTimeout | profile-before-change | CamerasParent 1]
Categories
(Core :: WebRTC: Audio/Video, defect, P2)
Tracking
()
People
(Reporter: pehrsons, Assigned: mjf)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
+++ This bug was initially created as a clone of Bug #1576335 +++
See crash-report: https://crash-stats.mozilla.org/report/index/ab924bb2-2ffe-46b7-a399-7ab470220127
Where the VideoCapture thread is waiting to join the CaptureThread, which is hanging on a poll on the device fd at shutdown timeout time.
It seems obvious that the CaptureThread can get stuck in an infloop here since there are two early returns that evade the stop-signal from the VideoCapture thread and hence keeps the loop going.
Reporter | ||
Comment 1•3 years ago
|
||
Michael, do you want some low hanging fruit? 😄
Comment 2•3 years ago
|
||
Set release status flags based on info from the regressing bug 1407415
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 3•3 years ago
|
||
Heh - I can add this to my list.
Comment 4•3 years ago
|
||
I had a quick look at the code, I'm a little confused.
VideoCaptureModuleV4L2::StopCapture() tries to join the thread that is looping on VideoCaptureModuleV4L2::CaptureProcess(), but if there is no event, it returns "true" without checking quit_...
Patch coming.
Comment 5•3 years ago
|
||
Comment 6•3 years ago
|
||
Patch attached, let me know if I pinged the wrong reviewers, that part of the submission process is unclear to me.
Comment 7•3 years ago
|
||
I should mention that this is triggered because I have a slightly buggy webcam that refuses to properly capture frames in MJPEG randomly. In any case, it shouldn't deadlock.
Comment 8•3 years ago
|
||
Olivier, thanks for finding the deadlock and the patch! This code is vendored in from the WebRTC native library project and we should get this submitted and reviewed upstream. Michael and I are happy to help with that. Then we can get this landed here.
Comment 9•3 years ago
|
||
I submitted it to our friends at the WebRTC project. https://webrtc-review.googlesource.com/c/src/+/251540
Updated•3 years ago
|
Comment 10•3 years ago
|
||
This patch was accepted upstream https://webrtc.googlesource.com/src/+/974f6c64388614c332671c98dec8fffc86f35acf . Rebased try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=57f6480d11763ae15ea7d8888ca257821a992146
Updated•3 years ago
|
Comment 11•3 years ago
|
||
Comment 12•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 13•3 years ago
|
||
Looks like we're still seeing reports from builds with the fix from comment 11:
bp-802d82cc-20f4-42a5-b065-235c40220326
bp-6189dac0-6217-45b3-9a76-35e560220328
bp-07589715-b212-43fc-b685-7d41d0220331
bp-076e338e-52cf-4784-b35e-0a9130220403
Does this look like the same root cause (and should we reopen this bug?) or should we file a new bug for the remaining ones?
Assignee | ||
Comment 14•3 years ago
|
||
Andreas did the initial analysis, so I'm not completely sure. However, since I don't see other threads waiting in poll, this seems like a new bug.
Reporter | ||
Comment 15•3 years ago
|
||
This bug was linux specific, FWIW.
Comment 16•3 years ago
|
||
I can confirm that it is fixed in the final version 100 for me.
Description
•