1399012 - crash at null in [@ mozilla::dom::ContentChild::ProcessingError]

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect, P3)

Description

[Tyson Smith [:tsmith]]

Attachment: test_case.html

==1816==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f22a04ab4a6 bp 0x7ffe0bf10df0 sp 0x7ffe0bf10df0 T0)
==1816==The signal is caused by a WRITE memory access.
==1816==Hint: address points to the zero page.
    #0 0x7f22a04ab4a5 in mozilla::dom::ContentChild::ProcessingError(mozilla::ipc::HasResultCodes::Result, char const*) /src/dom/ipc/ContentChild.cpp:2366:3
    #1 0x7f229b5c3ec9 in mozilla::ipc::IPCResult::Fail(mozilla::NotNull<mozilla::ipc::IProtocol*>, char const*, char const*) /src/ipc/glue/ProtocolUtils.cpp:65:39
    #2 0x7f22a052b9d0 in mozilla::dom::TabChild::RecvShow(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::dom::ShowInfo const&, bool const&, nsSizeMode const&) /src/dom/ipc/TabChild.cpp:1261:12
    #3 0x7f229bb922d0 in mozilla::dom::PBrowserChild::OnMessageReceived(IPC::Message const&) /src/obj-firefox/ipc/ipdl/PBrowserChild.cpp:2958:20
    #4 0x7f229bce6440 in mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&) /src/obj-firefox/ipc/ipdl/PContentChild.cpp:5162:28
    #5 0x7f229b5ba749 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) /src/ipc/glue/MessageChannel.cpp:2110:25
    #6 0x7f229b5b7524 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) /src/ipc/glue/MessageChannel.cpp:2036:17
    #7 0x7f229b5b8d34 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) /src/ipc/glue/MessageChannel.cpp:1882:5
    #8 0x7f229b5b9388 in mozilla::ipc::MessageChannel::MessageTask::Run() /src/ipc/glue/MessageChannel.cpp:1915:15
    #9 0x7f229a7f7230 in mozilla::SchedulerGroup::Runnable::Run() /src/xpcom/threads/SchedulerGroup.cpp:396:25
    #10 0x7f229a81e32d in nsThread::ProcessNextEvent(bool, bool*) /src/xpcom/threads/nsThread.cpp:1039:14
    #11 0x7f229a823848 in NS_ProcessNextEvent(nsIThread*, bool) /src/xpcom/threads/nsThreadUtils.cpp:521:10
    #12 0x7f22a04a3a92 in SpinEventLoopUntil<mozilla::ProcessFailureBehavior::ReportToCaller, (lambda at /src/dom/ipc/ContentChild.cpp:1007:24)> /src/obj-firefox/dist/include/nsThreadUtils.h:323:25
    #13 0x7f22a04a3a92 in mozilla::dom::ContentChild::ProvideWindowCommon(mozilla::dom::TabChild*, mozIDOMWindowProxy*, bool, unsigned int, bool, bool, bool, nsIURI*, nsAString const&, nsACString const&, bool, bool*, mozIDOMWindowProxy**) /src/dom/ipc/ContentChild.cpp:1007
    #14 0x7f22a05274c0 in mozilla::dom::TabChild::ProvideWindow(mozIDOMWindowProxy*, unsigned int, bool, bool, bool, nsIURI*, nsAString const&, nsACString const&, bool, bool*, mozIDOMWindowProxy**) /src/dom/ipc/TabChild.cpp:1039:16
    #15 0x7f22a4f464cb in nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, char const*, char const*, bool, bool, bool, nsIArray*, bool, bool, nsIDocShellLoadInfo*, mozIDOMWindowProxy**) /src/toolkit/components/windowwatcher/nsWindowWatcher.cpp:852:24
    #16 0x7f22a4f4bdaf in OpenWindow2 /src/toolkit/components/windowwatcher/nsWindowWatcher.cpp:444:10
    #17 0x7f22a4f4bdaf in non-virtual thunk to nsWindowWatcher::OpenWindow2(mozIDOMWindowProxy*, char const*, char const*, char const*, bool, bool, bool, nsISupports*, bool, bool, nsIDocShellLoadInfo*, mozIDOMWindowProxy**) /src/toolkit/components/windowwatcher/nsWindowWatcher.cpp:416
    #18 0x7f229d0685c9 in nsGlobalWindow::OpenInternal(nsAString const&, nsAString const&, nsAString const&, bool, bool, bool, bool, bool, nsIArray*, nsISupports*, nsIDocShellLoadInfo*, bool, nsPIDOMWindowOuter**) /src/dom/base/nsGlobalWindow.cpp:12955:21
    #19 0x7f229d0695ea in OpenNoNavigate /src/dom/base/nsGlobalWindow.cpp:9027:10
    #20 0x7f229d0695ea in non-virtual thunk to nsGlobalWindow::OpenNoNavigate(nsAString const&, nsAString const&, nsAString const&, nsPIDOMWindowOuter**) /src/dom/base/nsGlobalWindow.cpp:9021
    #21 0x7f22a444cc1d in nsDocShell::InternalLoad(nsIURI*, nsIURI*, mozilla::Maybe<nsCOMPtr<nsIURI> > const&, bool, nsIURI*, unsigned int, nsIPrincipal*, nsIPrincipal*, unsigned int, nsAString const&, char const*, nsAString const&, nsIInputStream*, nsIInputStream*, unsigned int, nsISHEntry*, bool, nsAString const&, nsIDocShell*, nsIURI*, bool, nsIDocShell**, nsIRequest**) /src/docshell/base/nsDocShell.cpp:10184:17
    #22 0x7f22a44c77fd in nsDocShell::OnLinkClickSync(nsIContent*, nsIURI*, char16_t const*, nsAString const&, nsIInputStream*, nsIInputStream*, bool, nsIDocShell**, nsIRequest**, nsIPrincipal*) /src/docshell/base/nsDocShell.cpp:14430:17
...
full log attached.

Comment 1

[Tyson Smith [:tsmith]]

Attachment: log.txt

Comment 2

[Ryan VanderMeulen [:RyanVM]]

INFO: Last good revision: b25d6223cf67202d09930defbf08e6bacb60fc4d
INFO: First bad revision: ea67db1628e0ad1f96bd67fc9f28197cecb71561
INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b25d6223cf67202d09930defbf08e6bacb60fc4d&tochange=ea67db1628e0ad1f96bd67fc9f28197cecb71561

--> Bug 1374025

This has to be one of the more evil fuzzer testcases :). For the purposes of bisection, "bad" builds were considered to be the ones that crashed nearly instantaneously when loading the testcase while "good" ones were builds that soldiered on for better or for worse.

However, it should be noted that "good" builds are still a trainwreck with this testcase, even if they aren't instacrashing like "bad" ones. I'm honestly unconvinced that the bad behavior isn't better here because at least it fails fast before completely trashing everything in its wake.

Comment 3

[Kris Maglione [:kmag]]

*sigh*

Yes, crashing here probably isn't any wronger than the alternative here.

The more correct behavior would probably be to throw before we get anywhere near that many levels of IPC-dependent nested event loops...

Comment 4

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals

Comment 5

[Timea Cernea [:tbabos][inactive]]

Hey Jason,
Could you please update the flags for this bug in case it is still reproducible or close it otherwise? Thanks!

Comment 6

[Jason Kratzer [:jkratzer]]

I am unable to reproduce this issue on either mozilla-central rev f2cb3ed27e68 (tip) or mozilla-central rev 0cec40c582f0 (oldest available build). I think we can safely close this issue.