Closed Bug 1752326 Opened 3 years ago Closed 3 years ago

Crash in [@ AsyncShutdownTimeout | profile-before-change | CamerasParent 1]

Categories

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

Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
100 Branch
Tracking Status
firefox-esr91 --- wontfix
firefox96 --- wontfix
firefox97 --- wontfix
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 --- fixed

People

(Reporter: pehrsons, Assigned: mjf)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

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

Michael, do you want some low hanging fruit? 😄

Flags: needinfo?(mfroman)

Set release status flags based on info from the regressing bug 1407415

Has Regression Range: --- → yes

Heh - I can add this to my list.

Assignee: nobody → mfroman
Flags: needinfo?(mfroman)

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.

Patch attached, let me know if I pinged the wrong reviewers, that part of the submission process is unclear to me.

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.

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.

I submitted it to our friends at the WebRTC project. https://webrtc-review.googlesource.com/c/src/+/251540

Pushed by na-g@nostrum.com: https://hg.mozilla.org/integration/autoland/rev/75a02770d67a Prevent deadlock when stopping V4L2 capture. r=ng
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch

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?

Flags: needinfo?(mfroman)

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.

Flags: needinfo?(mfroman)

This bug was linux specific, FWIW.

I can confirm that it is fixed in the final version 100 for me.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: