Crash in [@ mozilla::dom::CanonicalBrowsingContext::RemoveDynEntriesFromActiveSessionHistoryEntry]
Categories
(Core :: DOM: Navigation, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox82 | --- | unaffected |
firefox83 | --- | fixed |
People
(Reporter: gsvelto, Assigned: smaug)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
Maybe Fission related. (DOMFissionEnabled=1)
Crash report: https://crash-stats.mozilla.org/report/index/c008e210-1163-4cf5-9cfe-bbbea0200923
Top 10 frames of crashing thread:
0 libxul.so mozilla::dom::CanonicalBrowsingContext::RemoveDynEntriesFromActiveSessionHistoryEntry docshell/base/CanonicalBrowsingContext.cpp:602
1 libxul.so mozilla::dom::ContentParent::RecvRemoveDynEntriesFromActiveSessionHistoryEntry dom/ipc/ContentParent.cpp:7007
2 libxul.so mozilla::dom::PContentParent::OnMessageReceived ipc/ipdl/PContentParent.cpp:13249
3 libxul.so mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2074
4 libxul.so mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1953
5 libxul.so mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:514
6 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1234
7 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:87
8 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:309
9 libxul.so nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137
Only two crashes on nightly with this signature but they're from different users, on different platforms and the stack trace is exactly the same so this is likely a valid issue. Peter can you have a look? It seems like this code was introduced in bug 1660868.
Assignee | ||
Comment 1•4 years ago
|
||
I wonder if this can happen if we have just moved session history from one CanonicalBrowsingContext to another.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
This is most probably caused by the fact that session history in parent pref used to be live until Sept 25.
But based on code auditing, I think there is in theory a racyness issue if
ContentParent::RecvRemoveDynEntriesFromActiveSessionHistoryEntry[1] is received right after CanonicalBrowsingContext::ReplacedBy call before the old browsing context has been discarded.
Assignee | ||
Comment 3•4 years ago
|
||
Pushed by opettay@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d3264bc23ed7 Crash in [@ mozilla::dom::CanonicalBrowsingContext::RemoveDynEntriesFromActiveSessionHistoryEntry], r=jesup
Comment 5•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Description
•