Closed Bug 1542539 Opened 6 years ago Closed 6 years ago

Assertion failure: false (Empty picture rect), at src/dom/media/MediaData.cpp:190

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox-esr60 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- fixed

People

(Reporter: tsmith, Assigned: bryce)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase)

Attachments

(3 files)

Attached video testcase.mp4 (deleted) —

Assertion failure: false (Empty picture rect), at src/dom/media/MediaData.cpp:190

#0 0x7f0a0b6af343 in mozilla::ValidateBufferAndPicture(mozilla::VideoData::YCbCrBuffer const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&) src/dom/media/MediaData.cpp:190:5
#1 0x7f0a0b6ae975 in mozilla::VideoData::CreateAndCopyData(mozilla::VideoInfo const&, mozilla::layers::ImageContainer*, long, mozilla::media::TimeUnit const&, mozilla::media::TimeUnit const&, mozilla::VideoData::YCbCrBuffer const&, bool, mozilla::media::TimeUnit const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::layers::KnowsCompositor*) src/dom/media/MediaData.cpp:338:8
#2 0x7f0a0bd1a37e in mozilla::FFmpegVideoDecoder<46465650>::CreateImage(long, long, long, nsTArray<RefPtr<mozilla::MediaData> >&) src/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:388:25
#3 0x7f0a0bd1950f in mozilla::FFmpegVideoDecoder<46465650>::DoDecode(mozilla::MediaRawData*, unsigned char*, int, bool*, nsTArray<RefPtr<mozilla::MediaData> >&) src/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp:228:22
#4 0x7f0a0bd17028 in mozilla::FFmpegDataDecoder<46465650>::DoDecode(mozilla::MediaRawData*, bool*, nsTArray<RefPtr<mozilla::MediaData> >&) src/dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:176:10
#5 0x7f0a0bd16a0a in mozilla::FFmpegDataDecoder<46465650>::ProcessDecode(mozilla::MediaRawData*) src/dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp:132:20
#6 0x7f0a0bd1da65 in decltype(*(fp).*fp0(Get<0ul>(fp1).PassAsParameter())) mozilla::detail::RunnableMethodArguments<mozilla::MediaRawData*>::applyImpl<mozilla::FFmpegDataDecoder<46465650>, RefPtr<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true> > (mozilla::FFmpegDataDecoder<46465650>::*)(mozilla::MediaRawData*), StoreRefPtrPassByPtr<mozilla::MediaRawData>, 0ul>(mozilla::FFmpegDataDecoder<46465650>*, RefPtr<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true> > (mozilla::FFmpegDataDecoder<46465650>::*)(mozilla::MediaRawData*), mozilla::Tuple<StoreRefPtrPassByPtr<mozilla::MediaRawData> >&, std::integer_sequence<unsigned long, 0ul>) src/obj-firefox/dist/include/nsThreadUtils.h:1122:12
#7 0x7f0a0bd1d9ec in _ZN7mozilla6detail23RunnableMethodArgumentsIJPNS_12MediaRawDataEEE5applyINS_17FFmpegDataDecoderILi46465650EEEMS7_F6RefPtrINS_10MozPromiseI8nsTArrayIS8_INS_9MediaDataEEENS_11MediaResultELb1EEEES3_EEEDTcl9applyImplfp_fp0_dtdefpT10mArgumentstlSt16integer_sequenceImJLm0EEEEEEPT_T0_ src/obj-firefox/dist/include/nsThreadUtils.h:1128:12
#8 0x7f0a0bd1d976 in mozilla::detail::MethodCall<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true>, RefPtr<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true> > (mozilla::FFmpegDataDecoder<46465650>::*)(mozilla::MediaRawData*), mozilla::FFmpegDataDecoder<46465650>, mozilla::MediaRawData*>::Invoke() src/obj-firefox/dist/include/mozilla/MozPromise.h:1292:47
#9 0x7f0a0bd1d66e in mozilla::detail::ProxyRunnable<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true>, RefPtr<mozilla::MozPromise<nsTArray<RefPtr<mozilla::MediaData> >, mozilla::MediaResult, true> > (mozilla::FFmpegDataDecoder<46465650>::*)(mozilla::MediaRawData*), mozilla::FFmpegDataDecoder<46465650>, mozilla::MediaRawData*>::Run() src/obj-firefox/dist/include/mozilla/MozPromise.h:1312:42
#10 0x7f0a064ccff5 in mozilla::TaskQueue::Runner::Run() src/xpcom/threads/TaskQueue.cpp:199:12
#11 0x7f0a0650baad in nsThreadPool::Run() src/xpcom/threads/nsThreadPool.cpp:244:14
#12 0x7f0a0650c1bc in non-virtual thunk to nsThreadPool::Run() src/xpcom/threads/nsThreadPool.cpp
#13 0x7f0a06502106 in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1180:14
#14 0x7f0a0650877c in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:486:10
#15 0x7f0a072a3d73 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:303:20
#16 0x7f0a071c897c in MessageLoop::RunInternal() src/ipc/chromium/src/base/message_loop.cc:315:10
#17 0x7f0a071c87f0 in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:290:3
#18 0x7f0a064fba7e in nsThread::ThreadFunc(void*) src/xpcom/threads/nsThread.cpp:454:11
#19 0x7f0a28f80165 in _pt_root src/nsprpub/pr/src/pthreads/ptthread.c:201:5
Flags: in-testsuite?

Mp4 with a 0 width and height track is causing us to hit an assert that says we shouldn't have such things. The code surrounding our assert suggests that a warning here may be more appropriate, as we do not assert on other unexpected cases.

Taking a quick look into the code paths that lead us here, we don't appear to have code that forbids decoders outputting 0 by 0 frames until we hit here.

Assignee: nobody → bvandyk
Priority: -- → P3

Warn instead of asserting since it's possible for decoders to give us 0 by 0
frames here.

Pushed by bvandyk@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/edb31d22aafa MediaData::ValidateBufferAndPicture warns on 0 by 0 dimension data instead of asserting. r=jya https://hg.mozilla.org/integration/autoland/rev/3e0f17ff1ccc Add crash test for mp4 with a 0 by 0 dimension track. r=jya
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

Testcase was landed in media crash tests. I locally verified it shows the bug before applying the fix.

Flags: in-testsuite? → in-testsuite+

Following this landing there are OOM errors in the test logs following this test. These are not real OOMs and should not impact other tests: the reason that OOMs are reported is that all failures in certain functions in the Ffmpeg decoder are reported as OOMs, despite these errors occurring due to invalid inputs being rejected. Bug 1577879 tracks fixing this.

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

Attachment

General

Created:
Updated:
Size: