Open Bug 1982919 Opened 8 months ago Updated 7 months ago

Assertion failure: IsVideoDecoding(), at /dom/media/MediaDecoderStateMachine.cpp:4000

Categories

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

x86_64
Linux
defect

Tracking

()

Tracking Status
firefox-esr115 --- wontfix
firefox-esr128 --- wontfix
firefox-esr140 --- wontfix
firefox142 --- wontfix
firefox143 --- wontfix
firefox144 --- fix-optional

People

(Reporter: jkratzer, Assigned: alwu)

References

(Blocks 1 open bug, Regression)

Details

(4 keywords, Whiteboard: [bugmon:bisected,confirmed])

Attachments

(1 file)

Testcase found while fuzzing mozilla-central rev 6c51cabb2e48 (built with: --enable-debug --enable-fuzzing).

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework --upgrade
$ python -m fuzzfetch --build 6c51cabb2e48 --debug --fuzzing  -n firefox
$ python -m grizzly.replay.bugzilla ./firefox/firefox <bugid>
Assertion failure: IsVideoDecoding(), at /dom/media/MediaDecoderStateMachine.cpp:4000

    ==598964==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x752b51cfd4a1 bp 0x752b4092c530 sp 0x752b4092c3e0 T599012)
    ==598964==The signal is caused by a WRITE memory access.
    ==598964==Hint: address points to the zero page.
        #0 0x752b51cfd4a1 in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:248:3
        #1 0x752b51cfd4a1 in mozilla::MediaDecoderStateMachine::RequestVideoData(mozilla::media::TimeUnit const&, bool) /dom/media/MediaDecoderStateMachine.cpp:4000:3
        #2 0x752b51dedbfa in mozilla::MediaDecoderStateMachine::LoopingDecodingState::HandleVideoWaited(mozilla::MediaData::Type) /dom/media/MediaDecoderStateMachine.cpp:1344:16
        #3 0x752b51e19338 in operator() /dom/media/MediaDecoderStateMachine.cpp:4095:32
        #4 0x752b51e19338 in InvokeMethod<(lambda at /dom/media/MediaDecoderStateMachine.cpp:4088:13), void ((lambda at /dom/media/MediaDecoderStateMachine.cpp:4088:13)::*)(mozilla::MediaData::Type) const, mozilla::MediaData::Type> /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:669:14
        #5 0x752b51e19338 in InvokeCallbackMethod<false, mozilla::MozPromise<mozilla::MediaData::Type, mozilla::WaitForDataRejectValue, true>, (lambda at /dom/media/MediaDecoderStateMachine.cpp:4088:13), void ((lambda at /dom/media/MediaDecoderStateMachine.cpp:4088:13)::*)(mozilla::MediaData::Type) const, mozilla::MediaData::Type> /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:683:7
        #6 0x752b51e19338 in mozilla::MozPromise<mozilla::MediaData::Type, mozilla::WaitForDataRejectValue, true>::ThenValue<mozilla::MediaDecoderStateMachine::WaitForData(mozilla::MediaData::Type)::$_2, mozilla::MediaDecoderStateMachine::WaitForData(mozilla::MediaData::Type)::$_3>::DoResolveOrRejectInternal(mozilla::MozPromise<mozilla::MediaData::Type, mozilla::WaitForDataRejectValue, true>::ResolveOrRejectValue&) /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:874:17
        #7 0x752b51caef22 in mozilla::MozPromise<mozilla::MediaData::Type, mozilla::WaitForDataRejectValue, true>::ThenValueBase::ResolveOrRejectRunnable::Run() /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:505:21
        #8 0x752b4dd278e4 in mozilla::AutoTaskDispatcher::TaskGroupRunnable::Run() /builds/worker/workspace/obj-build/dist/include/mozilla/TaskDispatcher.h:234:35
        #9 0x752b4dd22179 in mozilla::TaskQueue::Runner::Run() /xpcom/threads/TaskQueue.cpp:273:20
        #10 0x752b4dd484ce in nsThreadPool::Run() /xpcom/threads/nsThreadPool.cpp:456:14
        #11 0x752b4dd3f45a in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1153:16
        #12 0x752b4dd459bf in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:480:10
        #13 0x752b4e901678 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) /ipc/glue/MessagePump.cpp:299:20
        #14 0x752b4e85aad1 in RunHandler /ipc/chromium/src/base/message_loop.cc:367:3
        #15 0x752b4e85aad1 in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:349:3
        #16 0x752b4dd3adce in nsThread::ThreadFunc(void*) /xpcom/threads/nsThread.cpp:366:10
        #17 0x752b5e9a2a1f in _pt_root /nsprpub/pr/src/pthreads/ptthread.c:191:3
        #18 0x752b5ea47aa3 in start_thread ./nptl/pthread_create.c:447:8
        #19 0x752b5ead4c3b in clone3 ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:78:0
    
    ==598964==Register values:
    rax = 0x0000000000000000  rbx = 0x0000602c2068c940  rcx = 0x0000000000000fa0  rdx = 0x0000752b5ebaf563
    rdi = 0x0000752b5ebb0700  rsi = 0x0000000000000000  rbp = 0x0000752b4092c530  rsp = 0x0000752b4092c3e0
     r8 = 0x0000000000000000   r9 = 0x0000000000000003  r10 = 0x0000000000000000  r11 = 0x0000000000000293
    r12 = 0x0000000000000001  r13 = 0x0000752ab80018b8  r14 = 0x00000000003c0001  r15 = 0x0000752ab8001880
    UndefinedBehaviorSanitizer can not provide additional info.
    SUMMARY: UndefinedBehaviorSanitizer: SEGV (/home/jkratzer/builds/m-c-20250813091044-fuzzing-debug/libxul.so+0x82654a1) (BuildId: 0d442eb0e8d7640ff40ccdd45e4d9f059e616a10)
    ==598964==ABORTING
Attached file Testcase
Attachment #9506980 - Attachment filename: testcase.zip.undefined → testcase.zip

Verified bug as reproducible on mozilla-central 20250814095102-0a5fc8db79ed.
Unable to bisect testcase (Testcase reproduces on start build!):

Start: 0be9e6fdab7b5eb39e27461cbec046d8a0f9f951 (20240815040802)
End: 6c51cabb2e48997969eb68ba245067238fbe46ec (20250813091044)
BuildFlags: BuildFlags(asan=False, tsan=False, debug=True, fuzzing=True, coverage=False, valgrind=False, no_opt=False, fuzzilli=False, nyx=False, searchfox=False, afl=False)

Whiteboard: [bugmon:confirm] → [bugmon:bisected,confirmed]

A pernosco session for this bug can be found here.

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(jmathies)

In the pernosco recording:

  • The video queue is finished from DecodingFirstFrameState::HandleEndOfVideo().
  • On receipt of audio, the state advances to LoopingDecodingState.
  • mIsReachingVideoEOS is initialized to true from !mMaster->IsVideoDecoding().
  • LoopingDecodingState::Enter() intentionally requests the video data again.
  • RequestVideoData() does not expect to be called when the video queue has finished.

I guess this wouldn't have happened before https://hg.mozilla.org/mozilla-central/rev/3e647187e78b9f74a372031572e4b0a502f72658#l2.71

The assertion was added in https://hg.mozilla.org/mozilla-central/rev/dce407eb2097706959a4142c13dc4dea9da65709#l1.59

Alastor, should the VideoQueue() be finished while looping?
I assume not because LoopingDecodingState::HandleEndOfVideo() does not finish the queue?
But seeking states also might finish the queue.
Should VideoQueue().mEndOfStream be reset when entering LoopingDecodingState?

I assume IsVideoDecoding() should not return false while in LoopingDecodingState, so that, for example, HasLowDecodedVideo() will check the queue size even when at end of stream.
Perhaps similarly for DonePrerollingVideo().

Flags: needinfo?(alwu)
Keywords: regression
Regressed by: 1262276
See Also: → 1825027

S3 because bug 1825027 was S3.
I guess consequences might be to not buffer enough for looping, but that might rectify quickly when the next frame is decoded.

Severity: -- → S3
Flags: needinfo?(jmathies)

BufferingState can also finish the queue and presumably stop buffering on EOS.

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

Priority: -- → P3

(In reply to Karl Tomlinson (:karlt) from comment #6)

Alastor, should the VideoQueue() be finished while looping?
I assume not because LoopingDecodingState::HandleEndOfVideo() does not finish the queue?
But seeking states also might finish the queue.
Should VideoQueue().mEndOfStream be reset when entering LoopingDecodingState?

Yes, the media queue should not be finished during seamless looping because we will continuously feed more data into the queue. Thank you for the investigation, I will check them to see what the fix should be.

Assignee: nobody → alwu
Flags: needinfo?(alwu)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: