[Fission] Crash in [@ mozilla::ipc::WriteIPDLParam<T> | mozilla::dom::PContentChild::SendWindowClose]
Categories
(Core :: DOM: Content Processes, defect, P3)
Tracking
()
Fission Milestone | M5 |
People
(Reporter: mccr8, Assigned: mccr8)
References
Details
(Keywords: crash)
Crash Data
This bug is for crash report bp-38e72906-075e-45f6-b8aa-3a7b20191128.
Top 10 frames of crashing thread:
0 XUL void mozilla::ipc::WriteIPDLParam<mozilla::dom::BrowsingContext*&> ipc/glue/IPDLParamTraits.h:60
1 XUL mozilla::dom::PContentChild::SendWindowClose ipc/ipdl/PContentChild.cpp:7457
2 XUL mozilla::dom::BrowsingContext::Close docshell/base/BrowsingContext.cpp:973
3 XUL mozilla::dom::Window_Binding::close dom/bindings/WindowBinding.cpp:1831
4 XUL bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::CrossOriginThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3153
5 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:548
6 XUL Interpret js/src/vm/Interpreter.cpp:621
7 XUL js::RunScript js/src/vm/Interpreter.cpp:423
8 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:589
9 XUL js::fun_apply js/src/vm/JSFunction.cpp:1190
This is another Fission crash where we hit MOZ_RELEASE_ASSERT(!aParam->IsDiscarded()) (Cannot send discarded BrowsingContext between processes!).
This particular crash is one that I hit. I was buying a videogame on gog.com using PayPay. This popped up a PayPal window. I signed in, and clicked pay. The PayPal window went away, returning me to the main GoG window. It sat there doing something for a few seconds, then the tab crashed.
I've also bought something using PayPal on another site where PayPal was opened in a new tab, not a new window, and it didn't crash. I don't know if that is due to the way the new page was loaded, or if the crash is just racey somehow.
I don't see any other crashes with this signature, but there are some similar ones with the [@ mozilla::ipc::IPDLParamTraits<T>::Write ] signature, that will hopefully be split out into more specific signatures:
bp-5c8f0298-6579-4819-81d4-1bca50191202
bp-4759654e-2b11-475f-a6b3-94d860191202
bp-2147682f-187d-4162-b664-9384c0191129
bp-14fe2217-72e8-4b3d-8213-c978d0191129
Assignee | ||
Comment 1•5 years ago
|
||
The crash I was seeing looks different than all of the crashes I linked at the end of the comment. The ones I linked at the end of the comment look like they are in the parent process, Fission is not enabled, and they are ending up in the send via MaybeCloseWindowHelper::Notify.
In comparison, the crash I linked has Fission enabled, is in a child process, and is getting invoked from JS (specifically window.close). I'll keep this about the crash I saw, because that is the only Fission one.
Comment 2•5 years ago
|
||
Tracking for Fission dogfooding (M5).
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
Andreas, with crashes like bp-f6db124a-e05d-4914-ac61-e7bbf0191211, should we be concerned that we seem to be firing events on windows with discarded browsing contexts, or can we just drop the send window close message and not worry about it any further? (Matt's patch in bug 1602366 is doing that, but he's addressing a situation where we're only touching a discarded BC off a window close timer that doesn't do anything else.)
Comment 5•5 years ago
|
||
This is how we've done it so far at least. There a checks abound to see if a browsing context has been discarded, and if so do "nothing". But it is kind of hard to say that this is a general rule, it depends. Sorry for not being able to say something more clear :/
Assignee | ||
Comment 6•5 years ago
|
||
Alright. I'll just mark this as a dupe of bug 1602366 then, because Matt's fix will stop the immediate crash here, too.
Updated•5 years ago
|
Description
•