1795975 - remove nested event loop from _displayPrintingError(). Was Assertion failure: ((bool)(__builtin_expect(!!(!NS_FAILED_impl(rv)), 1))) || !self->mWebRTCAlive, at /dom/media/systemservices/CamerasParent.cpp:1128

Status: REOPENED

(Toolkit :: Printing, defect)

Description

[Jason Kratzer [:jkratzer]]

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

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch --build ac1330b68d3e --debug --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.html

Assertion failure: ((bool)(__builtin_expect(!!(!NS_FAILED_impl(rv)), 1))) || !self->mWebRTCAlive, at /dom/media/systemservices/CamerasParent.cpp:1128

    ==607327==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f10867a81f6 bp 0x7ffce7b2d4a0 sp 0x7ffce7b2d460 T607327)
    ==607327==The signal is caused by a WRITE memory access.
    ==607327==Hint: address points to the zero page.
        #0 0x7f10867a81f6 in operator() /dom/media/systemservices/CamerasParent.cpp:1128:9
        #1 0x7f10867a81f6 in mozilla::detail::RunnableFunction<mozilla::camera::CamerasParent::RecvPCamerasConstructor()::$_15>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:531:5
        #2 0x7f10826b2e9e in mozilla::RunnableTask::Run() /xpcom/threads/TaskController.cpp:538:16
        #3 0x7f108268b3b9 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /xpcom/threads/TaskController.cpp:851:26
        #4 0x7f1082689f43 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /xpcom/threads/TaskController.cpp:683:15
        #5 0x7f108268a1b3 in mozilla::TaskController::ProcessPendingMTTask(bool) /xpcom/threads/TaskController.cpp:461:36
        #6 0x7f10826b67b9 in operator() /xpcom/threads/TaskController.cpp:190:37
        #7 0x7f10826b67b9 in mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_1>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:531:5
        #8 0x7f10826a000f in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1205:16
        #9 0x7f10826a6092 in NS_ProcessNextEvent /xpcom/threads/nsThreadUtils.cpp:465:10
        #10 0x7f10826a6092 in SpinEventLoopUntil<mozilla::ProcessFailureBehavior::ReportToCaller, (lambda at /xpcom/threads/nsThreadManager.cpp:639:61)> /builds/worker/workspace/obj-build/dist/include/mozilla/SpinEventLoopUntil.h:176:25
        #11 0x7f10826a6092 in nsThreadManager::SpinEventLoopUntilInternal(nsTSubstring<char> const&, nsINestedEventLoopCondition*, mozilla::ShutdownPhase) /xpcom/threads/nsThreadManager.cpp:639:8
        #12 0x7f10826d7125 in NS_InvokeByIndex /xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:101
        #13 0x7f1083479b02 in Invoke /js/xpconnect/src/XPCWrappedNative.cpp:1626:10
        #14 0x7f1083479b02 in CallMethodHelper::Call() /js/xpconnect/src/XPCWrappedNative.cpp:1179:19
        #15 0x7f10834796e7 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) /js/xpconnect/src/XPCWrappedNative.cpp:1125:23
        #16 0x7f108347b428 in XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) /js/xpconnect/src/XPCWrappedNativeJSOps.cpp:965:10
        #17 0x1895cb7a405  (<unknown module>)
    
    UndefinedBehaviorSanitizer can not provide additional info.
    SUMMARY: UndefinedBehaviorSanitizer: SEGV /dom/media/systemservices/CamerasParent.cpp:1128:9 in operator()
    ==607327==ABORTING

Comment 1

[Jason Kratzer [:jkratzer]]

Attachment: Testcase

Comment 2

[Bugmon [:jkratzer for issues]]

Bugmon Analysis
Verified bug as reproducible on mozilla-central 20221018213916-b6e04e02b4f8.
Unable to bisect testcase (Testcase reproduces on start build!):

Start: e45ba61007d1f8771179c0cc258166930acd75a5 (20211020093007)
End: ac1330b68d3e7b231a177cfa1ac52e1b2199bb84 (20221017213658)
BuildFlags: BuildFlags(asan=False, tsan=False, debug=True, fuzzing=True, coverage=False, valgrind=False, no_opt=False, fuzzilli=False, nyx=False)

Comment 3

[Release mgmt bot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 4

[Release mgmt bot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 5

[Bugmon [:jkratzer for issues]]

Testcase crashes using the initial build (mozilla-central 20221017213658-ac1330b68d3e) but not with tip (mozilla-central 20221119085828-f7eac47f5daa.)

The bug appears to have been fixed in the following build range:

Start: 1fe6516895957ace782916c24629b55763a9bbc6 (20221110085318)
End: c1a7df2f329c13cefcd6cdc81bc8fd8278182f3a (20221110124913)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1fe6516895957ace782916c24629b55763a9bbc6&tochange=c1a7df2f329c13cefcd6cdc81bc8fd8278182f3a

jkratzer, can you confirm that the above bisection range is responsible for fixing this issue?
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Comment 6

[Jason Kratzer [:jkratzer]]

Nothing in the bisection range appears to be responsible for fixing this bug, and further, this was found via the fuzzers between 2022/11/16 and 2022/11/18. With that said, I can no longer reproduce this issue locally.

Comment 7

[Karl Tomlinson (:karlt)]

A pernosco trace from a reproduction using the steps in comment 0 identifies the problem.
The nsIAsyncShutdownClient#addBlocker() call is failing a recursion check.
The recursion limit is reached due to a large number of "Printing failed while starting the print job." alerts, each starting a nested event loop.

I haven't reproduced with the more recent changeset 7ea8042eaf1d0c5f78ccce2e79e3e13f73526c64, but _displayPrintingError() is still using nsIPromptService#alert(), which uses a nested event loop.
Nested event loops are only suitable if there is some limit (preferably zero) on the number of further nested event loops that can be created.
alert() is therefore not suitable for the parent process because we do not want to block all other activity in the parent process. FWIW HTML's alert() should block all other activity.

Comment 8

[Karl Tomlinson (:karlt)]

Attachment: js-stack from pernosco trace

Comment 9

[Paul Zühlcke [:pbz]]

Here is where we spin the event loop for sync alert: https://searchfox.org/mozilla-central/rev/dbec4165e4c26a0ff970b614842b689e8357593c/toolkit/components/prompts/src/Prompter.sys.mjs#1042

Could the alert call simply be switched over to Services.prompt.asyncAlert? https://searchfox.org/mozilla-central/rev/dbec4165e4c26a0ff970b614842b689e8357593c/toolkit/components/windowwatcher/nsIPromptService.idl#79
That shouldn't spin a nested event loop.

Comment 10

[Mark Striemer [:mstriemer]]

Should this move to another component?

Comment 11

[Paul Zühlcke [:pbz]]

It's printing code so I think it makes sense to have it in printing.

Comment 12

[Mark Striemer [:mstriemer]]

Ah, I see now. Thanks

Running the testcase on Nightly doesn't do anything for me, window.printPreview() doesn't appear to exist, but printing after triggers that alert.

Seems like this is enough to trigger that alert case though: data:text/html,<script>document.replaceChildren();window.print();</script>

Comment 13

[Mark Striemer [:mstriemer]]

Attachment: Bug 1795975 - Use asyncAlert for printing errors r?mconley,pbz