Closed Bug 1642735 Opened 4 years ago Closed 4 years ago

Assertion failure: !Failed(), at /builds/worker/workspace/obj-build/dist/include/mozilla/ErrorResult.h:582

Categories

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

defect

Tracking

()

RESOLVED FIXED
82 Branch
Tracking Status
firefox-esr68 --- wontfix
firefox-esr78 --- wontfix
firefox77 --- wontfix
firefox78 --- wontfix
firefox79 --- wontfix
firefox80 --- wontfix
firefox81 --- wontfix
firefox82 --- fixed

People

(Reporter: tsmith, Assigned: bryce)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, Whiteboard: [fuzzblocker])

Attachments

(3 files)

This issue is hit by fuzzers frequently and can limit the effectiveness of the fuzzers. Please prioritize it accordingly.

A reduced test case will be attached asap.

Assertion failure: !Failed(), at /builds/worker/workspace/obj-build/dist/include/mozilla/ErrorResult.h:582

0|0|libxul.so|mozilla::binding_danger::TErrorResult<mozilla::binding_danger::AssertAndSuppressCleanupPolicy>::~TErrorResult()|hg:hg.mozilla.org/mozilla-central:dom/bindings/ErrorResult.h:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|0|0x29
0|1|libxul.so|mozilla::ChromiumCDMProxy::RejectPromiseWithStateError(unsigned int, nsTString<char> const&)|hg:hg.mozilla.org/mozilla-central:dom/media/gmp/ChromiumCDMProxy.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|386|0x8
0|2|libxul.so|mozilla::ChromiumCDMProxy::Init(unsigned int, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&)::$_11::operator()() const::{lambda(RefPtr<mozilla::gmp::ChromiumCDMParent>)#1}::operator()(RefPtr<mozilla::gmp::ChromiumCDMParent>) const::{lambda(bool)#1}::operator()(bool) const|hg:hg.mozilla.org/mozilla-central:dom/media/gmp/ChromiumCDMProxy.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|106|0x8
0|3|libxul.so|mozilla::MozPromise<bool, mozilla::MediaResult, true>::ThenValue<mozilla::ChromiumCDMProxy::Init(unsigned int, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&)::$_11::operator()() const::{lambda(RefPtr<mozilla::gmp::ChromiumCDMParent>)#1}::operator()(RefPtr<mozilla::gmp::ChromiumCDMParent>) const::{lambda(bool)#1}, mozilla::ChromiumCDMProxy::Init(unsigned int, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&)::$_11::operator()() const::{lambda(RefPtr<mozilla::gmp::ChromiumCDMParent>)#1}::operator()(RefPtr<mozilla::gmp::ChromiumCDMParent>) const::{lambda(mozilla::MediaResult)#1}>::DoResolveOrRejectInternal(mozilla::MozPromise<bool, mozilla::MediaResult, true>::ResolveOrRejectValue&)|hg:hg.mozilla.org/mozilla-central:xpcom/threads/MozPromise.h:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|771|0x16
0|4|libxul.so|mozilla::MozPromise<bool, mozilla::MediaResult, true>::ThenValueBase::ResolveOrRejectRunnable::Run()|hg:hg.mozilla.org/mozilla-central:xpcom/threads/MozPromise.h:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|410|0x2b
0|5|libxul.so|mozilla::SchedulerGroup::Runnable::Run()|hg:hg.mozilla.org/mozilla-central:xpcom/threads/SchedulerGroup.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|146|0x11
0|6|libxul.so|nsThread::ProcessNextEvent(bool, bool*)|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThread.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|1211|0x11
0|7|libxul.so|NS_ProcessNextEvent(nsIThread*, bool)|hg:hg.mozilla.org/mozilla-central:xpcom/threads/nsThreadUtils.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|501|0xc
0|8|libxul.so|mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*)|hg:hg.mozilla.org/mozilla-central:ipc/glue/MessagePump.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|109|0x14
0|9|libxul.so|MessageLoop::RunInternal()|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|315|0x17
0|10|libxul.so|MessageLoop::Run()|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|290|0x8
0|11|libxul.so|nsBaseAppShell::Run()|hg:hg.mozilla.org/mozilla-central:widget/nsBaseAppShell.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|137|0xd
0|12|libxul.so|XRE_RunAppShell()|hg:hg.mozilla.org/mozilla-central:toolkit/xre/nsEmbedFunctions.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|909|0xe
0|13|libxul.so|mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*)|hg:hg.mozilla.org/mozilla-central:ipc/glue/MessagePump.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|237|0x5
0|14|libxul.so|MessageLoop::RunInternal()|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|315|0x17
0|15|libxul.so|MessageLoop::Run()|hg:hg.mozilla.org/mozilla-central:ipc/chromium/src/base/message_loop.cc:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|290|0x8
0|16|libxul.so|XRE_InitChildProcess(int, char**, XREChildData const*)|hg:hg.mozilla.org/mozilla-central:toolkit/xre/nsEmbedFunctions.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|740|0x5
0|17|firefox-bin|content_process_main(mozilla::Bootstrap*, int, char**)|hg:hg.mozilla.org/mozilla-central:ipc/contentproc/plugin-container.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|56|0x11
0|18|firefox-bin|main|hg:hg.mozilla.org/mozilla-central:browser/app/nsBrowserApp.cpp:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|303|0x20
0|19|libc.so.6||||0x21b97
0|20|firefox-bin|<name omitted>|hg:hg.mozilla.org/mozilla-central:mfbt/UniquePtr.h:8acda9da4ae71f0b6561cb2021bcb370e18ce80c|253|0x1d

I've seen this before but couldn't find that bug (maybe I've just seen it while debugging...). Reminder to myself to take another look.

A Pernosco session is available here: https://pernos.co/debug/29fjQFq9I_QGfihR2zsRRg/index.html

Assignee: nobody → bvandyk
Severity: -- → S3
Attached file testcase.html

The attached testcase can be used with grizzly to reproduce this issue.

pip install grizzly-framework
python3 -m grizzly.replay --xvfb ~/builds/mc-debug/firefox ./testcase.html  -p prefs.js --repeat 20
Attached file prefs.js

I've been hitting this a fair amount in my work on a different bug, so I'll be pitching in here as well.

Flags: needinfo?(bvandyk)
Flags: needinfo?(bvandyk)

When rejecting promises in ChromiumCDMProxy we pass an exception to MediaKeys to
represent the error that took place. However, if we do not have a any keys the
exception is not passed anywhere. Since these exceptions will assert on
destruction that they were handled we need to explicitly suppress the exception
when we don't have MediaKeys to avoid firing asserts.

The case we hit this issue in is during browser shutdown, so I think it makes
sense to ignore the exception. This is not a case of simply ignoring an
exception when it can be handled, this is that we're in a state where various
machinery is becoming unavailable and where it makes sense to not try and send
the exception any further.

Pushed by bvandyk@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5f67698e1e52 Suppress exceptions in ChromiumCDMProxy if we don't have MediaKeys. r=jbauman
Pushed by bvandyk@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fdaabda9a455 Suppress exceptions in ChromiumCDMProxy if we don't have MediaKeys. r=jbauman
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: