1753357 - Assertion failure: aTarget, at /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:1678

Status: NEW

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

Description

[Tyson Smith [:tsmith]]

Found with m-c 20220201-281df200fb3b (--enable-debug --enable-fuzzing) while trying to reproduce another issue.

Assertion failure: aTarget, at /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:1678

#0 0x5c01673b491c in decltype(fp2()) mozilla::detail::InvokeAsync<mozilla::RemoteMediaDataDecoder::Shutdown()::$_3>(nsISerialEventTarget*, char const*, mozilla::detail::AllowInvokeAsyncFunctionLVRef, mozilla::RemoteMediaDataDecoder::Shutdown()::$_3&&) /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:1678:3
#1 0x5c01673a4f00 in decltype(fp1()) mozilla::InvokeAsync<mozilla::RemoteMediaDataDecoder::Shutdown()::$_3>(nsISerialEventTarget*, char const*, mozilla::RemoteMediaDataDecoder::Shutdown()::$_3&&) /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:1699:10
#2 0x5c01673a4e26 in mozilla::RemoteMediaDataDecoder::Shutdown() /builds/worker/checkouts/gecko/dom/media/ipc/RemoteMediaDataDecoder.cpp:93:10
#3 0x5c01675c0606 in mozilla::AudioTrimmer::Shutdown() /builds/worker/checkouts/gecko/dom/media/platforms/wrappers/AudioTrimmer.cpp:65:20
#4 0x5c01675fc243 in mozilla::MediaDataDecoderProxy::Shutdown()::$_16::operator()() const /builds/worker/checkouts/gecko/dom/media/platforms/wrappers/MediaDataDecoderProxy.cpp:87:54
#5 0x5c01675fbb08 in mozilla::detail::ProxyFunctionRunnable<mozilla::MediaDataDecoderProxy::Shutdown()::$_16, mozilla::MozPromise<bool, bool, false> >::Run() /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:1643:29
#6 0x5c0160a195c8 in mozilla::TaskQueue::Runner::Run() /builds/worker/checkouts/gecko/xpcom/threads/TaskQueue.cpp:206:20
#7 0x5c0160a39a24 in nsThreadPool::Run() /builds/worker/checkouts/gecko/xpcom/threads/nsThreadPool.cpp:305:14
#8 0x5c0160a2e65c in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1189:16
#9 0x5c0160a36f22 in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:467:10
#10 0x5c0161c8baff in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) /builds/worker/checkouts/gecko/ipc/glue/MessagePump.cpp:300:20
#11 0x5c0161af0c87 in MessageLoop::RunInternal() /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:331:10
#12 0x5c0161af0c04 in MessageLoop::RunHandler() /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:324:3
#13 0x5c0161af0bbc in MessageLoop::Run() /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:306:3
#14 0x5c0160a29180 in nsThread::ThreadFunc(void*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:391:10
#15 0x1e000388a145 in _pt_root /builds/worker/checkouts/gecko/nsprpub/pr/src/pthreads/ptthread.c:201:5
#16 0x791779c746da in start_thread /build/glibc-S9d2JN/glibc-2.27/nptl/pthread_create.c:463
#17 0x3b171247e71e in __clone /build/glibc-S9d2JN/glibc-2.27/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Comment 1

[Tyson Smith [:tsmith]]

A Pernosco session is available here: https://pernos.co/debug/ywPYRVp-DNpbmzM3-2t-2w/index.html

Comment 2

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

This is us calling InvokeAsync with a null thread. This is happening because the RemoteDecoderManagerChild::Shutdown() was called, nulling the thread, before RemoteMediaDataDecoder::Shutdown(). Our expectation is the manager outlives decoders, but it appears in this case that XPCOM shutdown has caused the manager to shutdown prior to the decoder.

I'm not too concerned about this, but it would be nice to not block fuzzing. This is appears to be one of those "how much do we want to chase a smoother XPCOM shutdown experience" cases. Tyson, how much a problem is this for fuzzing?

Brainstorming things we could do:

• Use shutdown blockers.
• Detect if the thread is already nulled and reject the shutdown promise rather than trying to do anything with the thread.

Unless we have a compelling reason for needing to block shutdown on the decoders, I think I prefer the latter.

Comment 3

[Tyson Smith [:tsmith]]

(In reply to Bryce Seager van Dyk (:bryce) from comment #2)

Tyson, how much a problem is this for fuzzing?

We see it a few times a day. It does not seem to be blocking, so not much of a problem.