Closed Bug 1267931 Opened 8 years ago Closed 8 years ago

crash in shutdownhang | mozilla::WMFMediaDataDecoder::ProcessFlush()

Categories

(Core :: Audio/Video: Playback, defect)

47 Branch
x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1274498

People

(Reporter: jwwang, Unassigned)

References

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-936734a4-0018-499f-b9f0-e4d012160426.
=============================================================

Thread 50, 57, 60, 62, 64, 65, 67
mozilla::WMFMediaDataDecoder::ProcessFlush()
Not sure if these threads are stuck in ProcessFlush().

Thread 44, 46, 47, 48, 51, 52, 54, 56
mozilla::WMFMediaDataDecoder::Flush()
It is interesting the number of threads that are calling Flush() do not equal the number of threads that are calling ProcessFlush().
Blocks: 1267752
(In reply to JW Wang [:jwwang] from comment #0)
Thread 50, 57, 60, 62, 64, 65, 67
> mozilla::WMFMediaDataDecoder::ProcessFlush()
> Not sure if these threads are stuck in ProcessFlush().
> 
> Thread 44, 46, 47, 48, 51, 52, 54, 56
> mozilla::WMFMediaDataDecoder::Flush()
> It is interesting the number of threads that are calling Flush() do not
> equal the number of threads that are calling ProcessFlush().

Flush will be called on the reader's taskqueue.

ProcessFlush runs on the MediaDataDecoder FlushableTaskQueue

So ProcessFlush threads will never match the one of Flush (and it's the same with most MediaDataDecoder implementations)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.