Closed Bug 1668682 Opened 5 years ago Closed 5 years ago

Crash in [@ mozilla::dom::WindowGlobalParent::GetBrowserParent]

Categories

(Core :: DOM: Navigation, defect, P2)

Desktop
All
defect

Tracking

()

RESOLVED FIXED
85 Branch
Fission Milestone M7
Tracking Status
firefox-esr78 --- unaffected
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 --- fixed

People

(Reporter: ash153311, Assigned: farre)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/4c03b6c4-094e-4fb5-a805-46aaa0201001

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::WindowGlobalParent::GetBrowserParent dom/ipc/WindowGlobalParent.cpp:211
1 xul.dll mozilla::net::DocumentLoadListener::OnStartRequest netwerk/ipc/DocumentLoadListener.cpp:2151
2 xul.dll mozilla::net::ParentChannelListener::OnStartRequest netwerk/protocol/http/ParentChannelListener.cpp:90
3 xul.dll nsDocumentOpenInfo::OnStartRequest uriloader/base/nsURILoader.cpp:166
4 xul.dll mozilla::net::ParentProcessDocumentOpenInfo::OnStartRequest netwerk/ipc/DocumentLoadListener.cpp:322
5 xul.dll mozilla::extensions::ChannelWrapper::RequestListener::OnStartRequest toolkit/components/extensions/webrequest/ChannelWrapper.cpp:1074
6 xul.dll mozilla::net::nsHttpChannel::CallOnStartRequest netwerk/protocol/http/nsHttpChannel.cpp:2067
7 xul.dll mozilla::net::nsHttpChannel::ContinueOnStartRequest3 netwerk/protocol/http/nsHttpChannel.cpp:7922
8 xul.dll mozilla::net::nsHttpChannel::ContinueOnStartRequest2 netwerk/protocol/http/nsHttpChannel.cpp:7902
9 xul.dll mozilla::net::nsHttpChannel::OnStartRequest netwerk/protocol/http/nsHttpChannel.cpp:7839
OS: Windows 10 → All
Hardware: Unspecified → Desktop

Maybe something extension-related here?

Component: General → DOM: Navigation
Flags: needinfo?(tomica)

Looks like a null deref on this line in DocumentLoadListener::OnStartRequest():
RefPtr<BrowserParent> browserParent = loadingContext->GetCurrentWindowGlobal()->GetBrowserParent();

Maybe GetCurrentWindowGlobal() is null? There's an assertion and a comment ("If we're not going to process switch, then we must have an existing window global, right?") that seems to think it can't happen but maybe it is mistaken.

The release crash is happening in nsFrameLoader::StartPersistence(), but maybe it is another missing null check on this similar-looking line: RefPtr<BrowserParent> browserParent = canonical->GetCurrentWindowGlobal()->GetBrowserParent();

The null deref on this line in DocumentLoadListener::OnStartRequest() shouldn't happen because this should be used only with pref browser.tabs.documentchannel.parent-controlled=true which doesn't work yet and is not recommended for use.
We can re-use this bug to fix the missing null check in nsFrameLoader::StartPersistence() and other instances, if there are any.

Assignee: nobody → afarre
Severity: -- → S3
Status: NEW → ASSIGNED
Fission Milestone: --- → M7
Flags: needinfo?(tomica)
Priority: -- → P2
Pushed by afarre@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f8f181536d0e Don't try to save browsing contexts without window. r=peterv
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: