Crash in [@ mozilla::ipc::IPDLParamTraits<T>::Write | mozilla::dom::PContentChild::SendCacheBrowsingContextChildren] from print preview
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
Fission Milestone | M7 |
People
(Reporter: mccr8, Unassigned)
Details
(Keywords: crash, Whiteboard: [fission-])
Crash Data
This bug is for crash report bp-d0b9d0f7-cb0e-4e55-a359-66c2d0191212.
Top 10 frames of crashing thread:
0 xul.dll static void mozilla::ipc::IPDLParamTraits<mozilla::dom::BrowsingContext*>::Write docshell/base/BrowsingContext.cpp:1302
1 xul.dll mozilla::dom::PContentChild::SendCacheBrowsingContextChildren ipc/ipdl/PContentChild.cpp:7111
2 xul.dll nsresult nsDocShell::SetupNewViewer docshell/base/nsDocShell.cpp:8364
3 xul.dll nsresult nsDocShell::Embed docshell/base/nsDocShell.cpp:6154
4 xul.dll nsDocShell::CreateAboutBlankContentViewer docshell/base/nsDocShell.cpp:6991
5 xul.dll nsresult nsDocShell::InitOrReusePrintPreviewViewer docshell/base/nsDocShell.cpp:13042
6 xul.dll XPTC__InvokebyIndex
7 @0x86e3b7
8 xul.dll trunc
9 xul.dll static bool XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1149
This is another bug where we are trying to send a discarded BC across IPC. In the crashes I spot checked, it seems to always happen inside a call to nsDocShell::InitOrReusePrintPreviewViewer. This is happening on 70, 71 and 72, not later versions, so it can't be a Fission issue.
It is much rarer on 72. Here's a 72 crash: bp-07687c5d-1bef-4728-a740-f39b70191211
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Whiteboard: [not Fission-specific]
This bug is not Fission specific, but let's track it for Fission Beta (M7) to make sure the crash volume doesn't increase with Fission.
99% of the crash reports are from Windows.
Comment 2•4 years ago
|
||
The priority flag is not set for this bug.
:kmag, could you have a look please?
For more information, please visit auto_nag documentation.
Reporter | ||
Updated•4 years ago
|
Comment 3•4 years ago
|
||
Closing as WFM. We had a small spike in December, but we haven't seen any crash reports for this signature since December 18.
Updated•4 years ago
|
Description
•