Crash in [@ mozilla::ipc::IPDLParamTraits<T>::Write | mozilla::ipc::WriteIPDLParam<T> | mozilla::dom::PContentChild::SendWindowClose]
Categories
(Core :: DOM: Content Processes, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox71 | --- | unaffected |
firefox72 | --- | fixed |
firefox73 | --- | fixed |
People
(Reporter: philipp, Assigned: mattwoodrow)
References
(Regression)
Details
(Keywords: crash, regression, Whiteboard: [not Fission-specific])
Crash Data
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
This bug is for crash report bp-2c68ce48-6e14-472c-832b-d338e0191208.
Top 10 frames of crashing thread:
0 xul.dll mozilla::ipc::IPDLParamTraits<mozilla::dom::BrowsingContext*>::Write docshell/base/BrowsingContext.cpp:1414
1 xul.dll static void mozilla::ipc::WriteIPDLParam<const RefPtr<mozilla::dom::BrowsingContext>&> ipc/glue/IPDLParamTraits.h:60
2 xul.dll mozilla::dom::PContentChild::SendWindowClose ipc/ipdl/PContentChild.cpp:7457
3 xul.dll mozilla::dom::BrowsingContext::Close docshell/base/BrowsingContext.cpp:980
4 xul.dll nsresult MaybeCloseWindowHelper::Notify docshell/base/nsDSURIContentListener.cpp:67
5 xul.dll void nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp
6 xul.dll nsresult nsTimerEvent::Run xpcom/threads/TimerThread.cpp:260
7 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1250
8 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
9 xul.dll void mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:88
these browser crashes are starting to show up in 32bit windows builds in the 72.0b cycle, looking related to the changes from bug 1589270.
all the reports are coming with MOZ_RELEASE_ASSERT(!aParam->IsDiscarded()) (Cannot send discarded BrowsingContext between processes!)
that got added in bug 1563604, and they mostly seem to happen on some urls used for filesharing (veryfastdrive.xyz, firebaseurl.xyz).
Comment 1•4 years ago
|
||
Bug 1600684 is about a similar crash, but it looks like there are two separate issues. I think it is fine to have bug 1600684 be about when Fission is enabled, and this one be about when Fission is disabled.
Comment 2•4 years ago
|
||
Matt, could you take a look? Comment 0 says it might be a regression from some document channel work. Thanks.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
Depends on D56820
Updated•4 years ago
|
Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/771cac79ef3a Don't try to close if we're already discarded. r=mccr8
Comment 5•4 years ago
|
||
bugherder |
Comment 6•4 years ago
|
||
Might be worth uplifting this so the regression doesn't go to release?
Updated•4 years ago
|
Assignee | ||
Comment 7•4 years ago
|
||
Comment on attachment 9115323 [details]
Bug 1602366 - Don't try to close if we're already discarded. r?mccr8
Beta/Release Uplift Approval Request
- User impact if declined: Browser crashes in rare cases when doing downloads.
- 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: Unknown, looks like a race condition.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Just checks for the exact same condition that we are asserting on.
- String changes made/needed:
Comment 8•4 years ago
|
||
Comment on attachment 9115323 [details]
Bug 1602366 - Don't try to close if we're already discarded. r?mccr8
crash fix, approved for 72.0b7
Comment 9•4 years ago
|
||
bugherder uplift |
Updated•4 years ago
|
Updated•4 years ago
|
Description
•