Closed Bug 1575842 Opened 4 months ago Closed 4 months ago

Crash in [@ MaybePageAlloc]

Categories

(Core :: Memory Allocator, defect, critical)

Desktop
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- unaffected
firefox70 --- fixed

People

(Reporter: marcia, Assigned: dimi)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug is for crash report bp-4198fb8f-dea1-4127-a61f-b8bf20190822.

Seen while looking at nightly crash triage - crashes started in 20190821215524: https://bit.ly/2HgP3GM

Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e7e658ec1e98c3868b98195c2ee4b9fe3842172e&tochange=835d0d9cdae81b3ab583d4ccf7459d00b041fad6

Not sure what in that changeset might have triggered it, ni on :jonco since there are a few memory related fixed in that changeset

Top 10 frames of crashing thread:

0 mozglue.dll MaybePageAlloc memory/replace/phc/PHC.cpp:908
1 mozglue.dll replace_malloc memory/replace/phc/PHC.cpp:943
2 xul.dll nsTSubstring<char16_t>::StartBulkWriteImpl xpcom/string/nsTSubstring.cpp:203
3 xul.dll nsTSubstring<char16_t>::Assign xpcom/string/nsTSubstring.cpp:408
4 xul.dll mozilla::NtPathToDosPath xpcom/io/FileUtilsWin.h:51
5 xul.dll void `anonymous namespace'::WinIOAutoObservation::WinIOAutoObservation xpcom/build/PoisonIOInterposerWin.cpp:134
6 xul.dll static long `anonymous namespace'::InterposedNtCreateFile xpcom/build/PoisonIOInterposerWin.cpp:207
7 kernelbase.dll CreateFileInternal 
8 kernelbase.dll CreateFileW 
9 xul.dll OpenFile xpcom/io/nsLocalFileWin.cpp:462

Flags: needinfo?(jcoppeard)

Looks like stack overflow caused by excessive recursion between mozilla::safebrowsing::Classifier::GetLookupCache and Classifier::ResetTables so more likely related to bug 1562822.

Flags: needinfo?(jcoppeard) → needinfo?(dlee)

The stack trace in the crash jumps from frame 89 to frame 1675, which does support the excessive recursion idea, as does the EXCEPTION_STACK_OVERFLOW crash reason.

Having said that, it is strange that the top 2 frames are in PHC, and the top 15 frames are not GetLookupCache and ResetTables. I'm not sure what to make of that.

Duplicate of this bug: 1575871

This patch replaces |ResetTables|(clear table's in-memory and on-disk
data) with |DeleteTables|(clear table's on-disk data) in GetLookupCache to avoid infinite
loop.

We can just delete on-disk data when file corruption is detected in |GetLookupCache|
without clearing the cache's internal data and refreshing current
active caches because in that scenario, the lookup cache failing to read
database has not yet added to the active caches list.

Crash Signature: [@ MaybePageAlloc] → [@ MaybePageAlloc] [@ _chkstk | MozStackWalkThread]
Pushed by dlee@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6d946d2a7a31
Do not use |ResetTables| when detecting Safe Browing database corruption in GetLookupCache. r=gcp
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Crash Signature: [@ MaybePageAlloc] [@ _chkstk | MozStackWalkThread] → [@ MaybePageAlloc] [@ _chkstk | MozStackWalkThread]
Flags: needinfo?(dlee)
Regressed by: 1562822
Duplicate of this bug: 1576454
Crash Signature: [@ MaybePageAlloc] [@ _chkstk | MozStackWalkThread] → [@ MaybePageAlloc] [@ _chkstk | MozStackWalkThread] [@ malloc_init | BaseAllocator::malloc | Allocator<T>::malloc | replace_malloc]
You need to log in before you can comment on or make changes to this bug.