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•1 year 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•1 year ago
|
||
Matt, could you take a look? Comment 0 says it might be a regression from some document channel work. Thanks.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 3•1 year ago
|
||
Depends on D56820
Updated•1 year 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•1 year ago
|
||
bugherder |
Comment 6•1 year ago
|
||
Might be worth uplifting this so the regression doesn't go to release?
Updated•1 year ago
|
Assignee | ||
Comment 7•1 year 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•1 year 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•1 year ago
|
||
bugherderuplift |
Description
•