Closed
Bug 1173860
Opened 9 years ago
Closed 9 years ago
crash in nsBaseHashtable<nsCStringHashKey, nsAutoPtr<mozilla::net::CacheEntryTable>, mozilla::net::CacheEntryTable*>::EnumerateRead(PLDHashOperator (*)(nsACString_internal const&, mozilla::net::CacheEntryTable*, void*), void*)
Categories
(Core :: Networking: Cache, defect)
Tracking
()
RESOLVED
FIXED
mozilla41
People
(Reporter: philipp, Assigned: away)
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
1.10 KB,
patch
|
mcmanus
:
review+
lizzard
:
approval-mozilla-aurora+
lizzard
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is report bp-08e99afe-44a6-4670-b14d-9340e2150610. ============================================================= filing this report since this crash is on #15 of the top crash list in firefox 39 beta as of now and had no associated bug yet. the crash seems to be predominantly happening on windows 7 32bit. one of the crash comments indicates that the screen goes black when the browser crashes and over 70% of crashes have a System Memory Use Percentage over 80... the top correlation is 99% vs 26% D3D10Warp.dll - not sure if this is significant.
There is some inlining, so the signature is a bit off, but in the disassembly I can see that sGlobalEntryTables is null during CollectReports, so the service must be mShutdown.
Component: Untriaged → Networking: Cache
I debated between testing sGlobalEntryTables versus testing mShutdown. I decided to go with sGlobalEntryTables based on the usage at CacheStorageService::SizeOfExcludingThis.
Assignee: nobody → dmajor
Attachment #8621080 -
Flags: review?(honzab.moz)
Updated•9 years ago
|
Crash Signature: [@ nsBaseHashtable<nsCStringHashKey, nsAutoPtr<mozilla::net::CacheEntryTable>, mozilla::net::CacheEntryTable*>::EnumerateRead(PLDHashOperator (*)(nsACString_internal const&, mozilla::net::CacheEntryTable*, void*), void*)] → [@ nsBaseHashtable<nsCStringHashKey, nsAutoPtr<mozilla::net::CacheEntryTable>, mozilla::net::CacheEntryTable*>::EnumerateRead(PLDHashOperator (*)(nsACString_internal const&, mozilla::net::CacheEntryTable*, void*), void*)]
[@ nsBaseHashtable<T>::Enumerate…
Updated•9 years ago
|
Attachment #8621080 -
Flags: review?(honzab.moz) → review+
Comment 4•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/291d1ba8961c
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox41:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Reporter | ||
Comment 5•9 years ago
|
||
[Tracking Requested - why for this release]: we have a fix that should make it into firefox 39, before it's released
status-firefox38.0.5:
--- → unaffected
status-firefox39:
--- → affected
status-firefox40:
--- → affected
status-firefox-esr38:
--- → unaffected
tracking-firefox39:
--- → ?
Comment on attachment 8621080 [details] [diff] [review] Null check Approval Request Comment [Feature/regressing bug #]: 964039 [User impact if declined]: crashes [Describe test coverage new/current, TreeHerder]: none [Risks and why]: trivial null-check [String/UUID change made/needed]: none
Attachment #8621080 -
Flags: approval-mozilla-beta?
Attachment #8621080 -
Flags: approval-mozilla-aurora?
Comment 7•9 years ago
|
||
Tracking enabled for 39, because there is a fix for 39 that should make it in before release, and this is a top crash for Win7.
Comment 8•9 years ago
|
||
Comment on attachment 8621080 [details] [diff] [review] Null check Approved for uplift, looks like we should have this in beta 7.
Attachment #8621080 -
Flags: approval-mozilla-beta?
Attachment #8621080 -
Flags: approval-mozilla-beta+
Attachment #8621080 -
Flags: approval-mozilla-aurora?
Attachment #8621080 -
Flags: approval-mozilla-aurora+
Comment 9•9 years ago
|
||
dmajor: how could this be a new regression in 39, but be caused by bug 964039 which landed a year ago?
Flags: needinfo?(dmajor)
Assignee | ||
Comment 12•9 years ago
|
||
(In reply to Liz Henry (:lizzard) from comment #9) > dmajor: how could this be a new regression in 39, but be caused by bug > 964039 which landed a year ago? The crash has been around for a while. (I'm not sure I agree with that "status-firefox38.0.5" assessment.) In the past it was too low volume to be noticed though.
Flags: needinfo?(dmajor)
Comment 13•9 years ago
|
||
OK thanks. flag tweaked for the sake of ... truth? :)
status-firefox38:
--- → ?
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•