1611588 - Crash in [@ mozilla::dom::ExternalHelperAppParent::Init]

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[[:philipp]]

[Tracking Requested - why for this release]:

This bug is for crash report bp-700cb11c-7c27-430c-ba87-fc20f0200125.

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::ExternalHelperAppParent::Init uriloader/exthandler/ExternalHelperAppParent.cpp:83
1 xul.dll mozilla::dom::ContentParent::RecvPExternalHelperAppConstructor dom/ipc/ContentParent.cpp:3826
2 xul.dll mozilla::dom::PContentParent::OnMessageReceived ipc/ipdl/PContentParent.cpp:8388
3 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2134
4 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1241
5 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
6 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:109
7 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308
8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
9 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137

this crash signature is showing up in 73.0b9 and accounting for 1.7% of browser crashes in early stability data there. presumably the disabling of DocumentChannel triggered this spike.

Comment 1

[[:philipp]]

hi matt, can you take a look at that issue?

Comment 2

[Chris Peterson [:cpeterson]]

DocumentChannel was (supposed to have been) disabled in 73.0b9 (by bug 1610888). This ExternalHelperAppParent::Init crash signature appeared in 72.* builds but not in 73.0b < b9. Perhaps this crash was fixed by DocumentChannel and now reappeared because DocumentChannel was disabled?

https://crash-stats.mozilla.org/search/?signature=~mozilla%3A%3Adom%3A%3AExternalHelperAppParent%3A%3AInit&product=Firefox&date=%3E%3D2019-07-30T10%3A02%3A00.000Z&date=%3C2020-01-30T10%3A02%3A00.000Z&_facets=signature&_facets=version&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-version

Comment 3

[Matt Woodrow (:mattwoodrow)]

Attachment: Bug 1611588 - Handle null BrowsingContext in ExternalHelperAppParent. r?bzbarsky

Comment 4

[Ryan VanderMeulen [:RyanVM]]

This blocks the 73 release given the volume.

Comment 5

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 9123688 [details]
Bug 1611588 - Handle null BrowsingContext in ExternalHelperAppParent. r?bzbarsky

Beta/Release Uplift Approval Request

• User impact if declined: Null pointer crashes for some download cases
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce: No known STR at this point.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Just adding a null check
• String changes made/needed:

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3e9ae7057301
Handle null BrowsingContext in ExternalHelperAppParent. r=nika

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9123688 [details]
Bug 1611588 - Handle null BrowsingContext in ExternalHelperAppParent. r?bzbarsky

Fixes a release-blocking topcrash. Approved for 73.0RC1.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/e7cc084121fa

Comment 9

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/3e9ae7057301

Comment 12

[Firefox Bug Husbandry Bot]

Please specify a root cause for this bug. See :tmaity for more information.

Comment 13

[Nhi Nguyen (:nhi)]

NI Matt for RCA