Crash in [@ mozilla::WebMDemuxer::GetBuffered]
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox81 | --- | affected |
People
(Reporter: TD-Linux, Unassigned)
References
()
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
|
47.82 KB,
text/plain
|
Details |
I get this crash reliably when clicking the first video on the linked webpage and letting it play for a few seconds. I can't currently reproduce it with the same video as a file:// url or a local webserver, unfortunately.
This is very similar to bug 1530897 but the triggering method is different so I am not sure it is really the same. Also it's a SIGSEGV, not an assertion failure. It could also be 1532290 but I'm not sure.
This bug is for crash report bp-33e8bd7f-4ae1-44c9-86d4-0a5200200731.
Top 10 frames of crashing thread:
0 libxul.so mozilla::WebMDemuxer::GetBuffered dom/media/webm/WebMDemuxer.cpp:986
1 libxul.so mozilla::WebMTrackDemuxer::GetBuffered dom/media/webm/WebMDemuxer.cpp:1244
2 libxul.so mozilla::WebMTrackDemuxer::Reset dom/media/webm/WebMDemuxer.cpp:1177
3 libxul.so mozilla::detail::RunnableFunction<mozilla::MediaFormatReader::DemuxerProxy::Wrapper::Reset xpcom/threads/nsThreadUtils.h:577
4 libxul.so mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:158
5 libxul.so nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:299
6 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1234
7 libxul.so mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:332
8 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:309
9 libxul.so nsThread::ThreadFunc xpcom/threads/nsThread.cpp:447
Comment 1•5 years ago
|
||
bp-db7a64a1-5f36-44c9-840a-231500200801
URL: https://i.4cdn.org/wsg/1587869305778.webm
I got a tab crash while I was in another tab.
Comment 2•5 years ago
|
||
This is an assertion, that start <= end enforced by TimeInterval
Comment 3•5 years ago
|
||
Not sure if this is related to bug 1530897. In this case, the file reports a duration of 300s but the last frame has a timecode of 613.003s and a default track duration of 1s, making the true duration 614.003s.
WebMDemuxer clamps the end time to the duration, resulting in an attempt to construct a TimeInterval(611.783s, 300s) and triggering the assert.
I'm not clear why this clamping exists - it has been present since the file was created in bug 1148102. The old code (WebMReader.cpp) doesn't do this, instead it clamps the end time to the duration only in the case of IsDataCachedToEndOfResource returning true (which would still be wrong in this case, since we can't trust the reported duration).
Updated•5 years ago
|
Comment 4•3 years ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•