If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

MediaDecoder::Invalidate() may block the main thread for up to 8 seconds

RESOLVED WORKSFORME

Status

()

Core
Audio/Video: Playback
P1
normal
RESOLVED WORKSFORME
6 months ago
a month ago

People

(Reporter: cpearce, Unassigned)

Tracking

(Blocks: 1 bug, {stale-bug})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qf:p1][bhr])

Attachments

(1 attachment)

(Reporter)

Description

6 months ago
Created attachment 8863984 [details]
media.txt

BHR is reporting that sometimes the main thread is blocked for up to 8 seconds while MediaDecoder::Invalidate() is on the stack.

I'll attach a list of the entry point pseudo stacks.

We have 92 reports in the reports from 29 April: https://people-mozilla.org/~mlayzell/bhr/20170429/hangs.json

I haven't dived into the causes yet.
Whiteboard: [qf:p1] → [qf:p1][bhr]
Blocks: 1364015
Hi Chris,
Do you know whether the reports are gathered from Nightly users or computers dedicated to tests like Try? Does it exclude the case (false positive) where the computer is busy or CPU cycles are drained by some other programs?
Flags: needinfo?(cpearce)
(Reporter)

Comment 2

5 months ago
This comes from telemetry from Nightly users. We capture the main thread stack if it's blocked for more than 8 seconds (actually, the latest reports have the threshold lowered to 125ms).

Yes, if the main thread happens to be busy for 8 seconds because the user's anti virus scanner or whatever is killing performance, we'll get hit here.

I think it would be useful to add telemetry to record how long we spend in this function; that would give us more evidence to back up the claims here.
Flags: needinfo?(cpearce)
Depends on: 1366640
No longer blocks: 1364015
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-06-06&keys=__none__!__none__!__none__&max_channel_version=nightly%252F55&measure=VFC_SETIMAGES_LOCK_HOLD_MS&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-06-06&table=0&trim=1&use_submission_date=0

The telemetry shows there are some SetCurrentFrames() calls that hold the lock for more than 1s. I will try to remove the use of lock on the main thread to prevent it from being blocked by other threads.
Depends on: 1377025
This is a P1 bug without an assignee. 

P1 are bugs which are being worked on for the current release cycle/iteration/sprint. 

If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.
Keywords: stale-bug
Flags: needinfo?(ajones)
JW - what is happening with this bug?
Flags: needinfo?(ajones) → needinfo?(jwwang)
Flags: needinfo?(ajones)
I believe bug 1377025 has fixed the issue. Per comment 2, it is possible to be a false alarm when the system is busy. I think we can close this bug and open a new one if there are new occurrences.
Flags: needinfo?(jwwang)
Status: NEW → RESOLVED
Last Resolved: a month ago
Flags: needinfo?(ajones)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.