Crash in [@ InvalidArrayIndex_CRASH | nsSHistory::EnsureCorrectEntryAtCurrIndex]
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox70 | --- | unaffected |
| firefox71 | --- | unaffected |
| firefox72 | --- | fixed |
People
(Reporter: marcia, Assigned: annyG)
References
(Blocks 1 open bug)
Details
(Keywords: crash, regression, testcase)
Crash Data
Attachments
(4 files)
This bug is for crash report bp-86cdd459-79f4-4931-a9c3-c27d30191107.
Seen while looking at nightly crash stats: https://bit.ly/2NuqnON. macOS crash which started in 20191106215426.
Possible regression range based on build id: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4d585c7edc7683e4b35eca6b18c9a646a1b8a78d&tochange=96b58f95ed7333672e6dba134d091015328d299b
Bug 1546761 touched code in this area. ni on :annyg
Top 10 frames of crashing thread:
0 xul.dll InvalidArrayIndex_CRASH xpcom/ds/nsTArray.cpp:27
1 xul.dll void nsSHistory::EnsureCorrectEntryAtCurrIndex docshell/shistory/nsSHistory.cpp:1388
2 xul.dll bool nsDocShell::OnNewURI docshell/base/nsDocShell.cpp:10812
3 xul.dll bool nsDocShell::OnLoadingSite docshell/base/nsDocShell.cpp:10866
4 xul.dll nsresult nsDocShell::CreateContentViewer docshell/base/nsDocShell.cpp:7916
5 xul.dll nsresult nsDSURIContentListener::DoContent docshell/base/nsDSURIContentListener.cpp:183
6 xul.dll bool nsDocumentOpenInfo::TryContentListener uriloader/base/nsURILoader.cpp:740
7 xul.dll nsresult nsDocumentOpenInfo::DispatchContent uriloader/base/nsURILoader.cpp:413
8 xul.dll nsresult nsDocumentOpenInfo::OnStartRequest uriloader/base/nsURILoader.cpp:292
9 xul.dll void mozilla::net::HttpChannelChild::DoOnStartRequest netwerk/protocol/http/HttpChannelChild.cpp:682
Comment 1•6 years ago
|
||
The crash reason for these crashes is
ElementAt(aIndex = 18446744073709551615, aLength = 0)
Looks like 18446744073709551615 is -1, so in a debug build we'd fail the assertion on the previous line, MOZ_ASSERT(mIndex > -1);
| Assignee | ||
Updated•6 years ago
|
Comment 2•6 years ago
|
||
This test seems to fairly reliably reproduce the crash when served from a webserver.
Please let me know if a Pernosco session would be helpful and I will create one.
Comment 3•6 years ago
|
||
Required to repro with attached test case.
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 4•6 years ago
|
||
Before bug 1546761 we would bail out in ReplaceEntry because index is < 0. We could put back that check in nsSHistory::EnsureCorrectEntryAtCurrIndex, but I'd like to understand why we have a -1 here. (The original code is from bug 1322896)
Comment 5•6 years ago
|
||
(In reply to Tyson Smith [:tsmith] from comment #2)
Please let me know if a Pernosco session would be helpful and I will create one.
I think that'd be useful, because this seems to require some fuzzing setup.
| Assignee | ||
Comment 6•6 years ago
|
||
Comment 7•6 years ago
|
||
A Pernosco session is available here: https://pernos.co/debug/nCFSls7ZcIz6eQOvqGEzLA/index.html
It will expire in 7 days.
Comment 8•6 years ago
|
||
Thanks for the recording. The reason this happens is because the pref browser.sessionhistory.max_entries is set to 0. That causes nsSHistory::PurgeHistory to be called when we add an entry, and that sets mRequestedIndex and mIndex to -1. We should add a test that sets browser.sessionhistory.max_entries to 0 and then navigates a bit.
| Assignee | ||
Comment 10•6 years ago
|
||
Updated•6 years ago
|
Comment 11•6 years ago
|
||
Comment 12•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/3af47ccb969a
https://hg.mozilla.org/mozilla-central/rev/11ce58dd1902
Description
•