Closed
Bug 392873
Opened 17 years ago
Closed 16 years ago
crash in nsExpirationTracker<nsSHEntry,3>::RemoveObject
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: techtonik, Assigned: roc)
Details
(Keywords: crash)
Attachments
(4 files, 1 obsolete file)
36.02 KB,
text/plain
|
Details | |
3.72 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
review+
bzbarsky
:
superreview+
damons
:
approval1.9+
|
Details | Diff | Splinter Review |
2.70 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
damons
:
approval1.9+
|
Details | Diff | Splinter Review |
2.71 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
mtschrep
:
approval1.9+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007081905 Minefield/3.0a8pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007081905 Minefield/3.0a8pre Crash occurred while working with GMail, not sure if it was a reason. Stacktrace attached. No talkback interface in this build. Reproducible: Sometimes
Updated•17 years ago
|
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → general
Comment 2•17 years ago
|
||
I experienced a similar crash today (I think I was waiting for a new page to load) with a SeaMonkey trunk build. It might have the same cause, but hard to tell since the original bug report does not contain a good stack or a Breakpad id. Anyway, here is the stack: 0:000> kp ChildEBP RetAddr 0012fc1c 02467698 docshell!nsExpirationTracker<nsSHEntry,3>::RemoveObject(class nsSHEntry * aObj = 0x02467521)+0x24 [f:\mozilla\tree-cvsmo\mozilla\objsuite\dist\include\xpcom\nsexpirationtracker.h @ 157] 0012fc24 0246748d docshell!HistoryTracker::NotifyExpired(class nsSHEntry * aObj = 0x02467521)+0x9 [f:\mozilla\tree-cvsmo\mozilla\docshell\shistory\src\nsshentry.cpp @ 70] 0012fc40 02467521 docshell!nsExpirationTracker<nsSHEntry,3>::AgeOneGeneration(void)+0x4b [f:\mozilla\tree-cvsmo\mozilla\objsuite\dist\include\xpcom\nsexpirationtracker.h @ 211] 0012fc48 002b88df docshell!nsExpirationTracker<nsSHEntry,3>::TimerCallback(class nsITimer * aTimer = 0x0028b3f7, void * aThis = 0x00000001)+0xc [f:\mozilla\tree-cvsmo\mozilla\objsuite\dist\include\xpcom\nsexpirationtracker.h @ 278] 0012fc58 002b8a26 xpcom_core!nsTimerImpl::Fire(void)+0x6d [f:\mozilla\tree-cvsmo\mozilla\xpcom\threads\nstimerimpl.cpp @ 384] 0012fc60 002b9312 xpcom_core!nsTimerEvent::Run(void)+0x1b [f:\mozilla\tree-cvsmo\mozilla\xpcom\threads\nstimerimpl.cpp @ 459] 0012fc80 0028b3f7 xpcom_core!nsThread::ProcessNextEvent(int mayWait = 1, int * result = 0x0012fc9c)+0xc3 [f:\mozilla\tree-cvsmo\mozilla\xpcom\threads\nsthread.cpp @ 491] 0012fc94 0160b60b xpcom_core!NS_ProcessNextEvent_P(class nsIThread * thread = 0x00000001, int mayWait = 1)+0x27 [f:\mozilla\tree-cvsmo\mozilla\objsuite\xpcom\build\nsthreadutils.cpp @ 227] 0012fca8 017818ef gkwidget!nsBaseAppShell::Run(void)+0x2a [f:\mozilla\tree-cvsmo\mozilla\widget\src\xpwidgets\nsbaseappshell.cpp @ 154] 0012fcb4 10007624 tkitcmps!nsAppStartup::Run(void)+0x1e [f:\mozilla\tree-cvsmo\mozilla\toolkit\components\startup\src\nsappstartup.cpp @ 171] 0012fef4 004012ce xul!XRE_main(int argc = 1, char ** argv = 0x003f6b88, struct nsXREAppData * aAppData = 0x003f6fa0)+0x127e [f:\mozilla\tree-cvsmo\mozilla\toolkit\xre\nsapprunner.cpp @ 3116] 0012ff24 00401325 seamonkey!main(int argc = 1, char ** argv = 0x003f6b88)+0xc1 [f:\mozilla\tree-cvsmo\mozilla\suite\app\nssuiteapp.cpp @ 100] 0012ff30 00401513 seamonkey!WinMain(struct HINSTANCE__ * __formal = 0x7c816fd7, struct HINSTANCE__ * __formal = 0x003f0000, char * args = 0x7c920732 "???", int __formal = 2147344384)+0x13 [f:\mozilla\tree-cvsmo\mozilla\suite\app\nssuiteapp.cpp @ 110] *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\kernel32.dll - 0012ffc0 7c816fd7 seamonkey!__tmainCRTStartup(void)+0x140 [f:\rtm\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 578] WARNING: Stack unwind information not available. Following frames may be wrong. 0012fff0 00000000 kernel32!RegisterWaitForInputIdle+0x49
Summary: crash in nsExpirationTracker<gfxFont,3>::CheckStartTimer → crash in nsExpirationTracker<gfxFont,3>::CheckStartTimer [@ nsExpirationTracker<nsSHEntry,3>::RemoveObject]
Comment 3•17 years ago
|
||
Breakpad also has some crash reports in that direction (limited search to one week): Rank Signature # Win Mac Lin 1 nsExpirationTracker<gfxFont, 3>::AddObject(gfxFont*) 61 61 0 0 2 nsExpirationTracker<nsSHEntry, 3>::RemoveObject(nsSHEntry*) 24 24 0 0
Comment 4•17 years ago
|
||
nsSHEntry using nsExpirationTracker is new. gfxFont is different (unless this is a bug in nsExpirationTracker itself). Most of the gfxFont crahes are from SeaMonkey and requires use of suite's old typeaheadfind (I can provide a testcase that will hit that consistently if it would be useful).
Keywords: crash
Comment 5•17 years ago
|
||
Maybe I should then split my crash in a new bug... :) (will do that later).
Assignee | ||
Comment 6•17 years ago
|
||
I don't suppose anyone has any idea how to reproduce this (nsSHEntry) crash?
Flags: blocking1.9?
Comment 7•17 years ago
|
||
Not really, no. I think one time I was waiting for a page to load and one time I was just reading a web page when it crashed.
Comment 8•17 years ago
|
||
Some additional information I got with a debug build (dunno if it helps), I crashed a few lines above in line 152: Many members of aObj are either 0xdddddddd, 0xdd or -572662307 (for the mScrollPositionX/Y members). Exceptions are mParent ([2] member under __vfptr is 0xdddddddd though), mCacheKey (same), mContentType, mDocument, mContentViewer (Windbg displays a "<Memory access error>" though for the values under __vfptr). No assertions or warnings in console before it crashed.
Assignee | ||
Comment 9•17 years ago
|
||
thanks. Looks like a deleted object is still in the tracker. I'll see if I can add some assertions to help track this down.
Assignee | ||
Comment 10•17 years ago
|
||
This should help track down the crash. Very simple brute-force checking
Assignee: nobody → roc
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #282343 -
Flags: superreview?(bzbarsky)
Attachment #282343 -
Flags: review?(bzbarsky)
Comment 11•17 years ago
|
||
Comment on attachment 282343 [details] [diff] [review] debugging code Let's true it
Attachment #282343 -
Flags: superreview?(bzbarsky)
Attachment #282343 -
Flags: superreview+
Attachment #282343 -
Flags: review?(bzbarsky)
Attachment #282343 -
Flags: review+
Assignee | ||
Updated•17 years ago
|
Attachment #282343 -
Flags: approval1.9?
Updated•17 years ago
|
Attachment #282343 -
Flags: approval1.9? → approval1.9+
Updated•17 years ago
|
Summary: crash in nsExpirationTracker<gfxFont,3>::CheckStartTimer [@ nsExpirationTracker<nsSHEntry,3>::RemoveObject] → crash in nsExpirationTracker<nsSHEntry,3>::RemoveObject
Assignee | ||
Comment 12•17 years ago
|
||
I checked in that patch ages ago. Is anyone still seeing this? I haven't seen it at all.
Reporter | ||
Comment 13•17 years ago
|
||
Seems to be stable now. I guess it can be closed if you checked in that patch after 2007-08-20
Assignee | ||
Comment 14•17 years ago
|
||
That patch was just debugging code. It shouldn't have fixed any bugs :-( I'll mark worksforme, I guess. At least the debugging code is there in case this flares up again.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.9?
Comment 15•17 years ago
|
||
I also do not see my (this) crash anymore. crash-reports.m.c shows a peak for the nsExpirationTracker<nsSHEnty,3> signature around 9-30. crash-reports.m.c shows that there are still a few crashes though on trunk with that stack trace.
Assignee | ||
Comment 16•17 years ago
|
||
I see 72 crashers in the last week. http://crash-stats.mozilla.com/report/list?range_unit=weeks&query_search=signature&query_type=contains&product=Firefox&version=Firefox%3A3.0a9pre&branch=1.9&signature=nsExpirationTracker%3CnsSHEntry%2C+3%3E%3A%3ARemoveObject(nsSHEntry*)&query=nsExpirationTracker&range_value=1 They're all over the place, seemingly at random. It looks like we have a deleted nsSHEntry in our expiration tracker. I just don't see how that can happen. Maybe I should change this debug code so that when we destruct an nsSHEntry, if it's still in the tracker then we cause a crash right then. That would give us a more useful stack. Let me do that.
Assignee | ||
Comment 17•17 years ago
|
||
Crash early in release builds if a destroyed nsSHEntry is still in the tracker. I'm also moving gHistoryTracker->AddObject(this) to an earlier position just in case one of the intervening calls is somehow destroying the nsSHEntry --- which shouldn't be possible, and would cause crashes elsewhere, I would think, but just in case...
Attachment #285527 -
Flags: superreview?(bzbarsky)
Attachment #285527 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 18•17 years ago
|
||
More crash-early instrumentation to detect if AddObject being called when the entry is already in the tracker is the cause of our problems.
Attachment #285527 -
Attachment is obsolete: true
Attachment #285547 -
Flags: superreview?(bzbarsky)
Attachment #285547 -
Flags: review?(bzbarsky)
Attachment #285527 -
Flags: superreview?(bzbarsky)
Attachment #285527 -
Flags: review?(bzbarsky)
Comment 19•17 years ago
|
||
Comment on attachment 285547 [details] [diff] [review] updated patch Let's do it.
Attachment #285547 -
Flags: superreview?(bzbarsky)
Attachment #285547 -
Flags: superreview+
Attachment #285547 -
Flags: review?(bzbarsky)
Attachment #285547 -
Flags: review+
Assignee | ||
Comment 20•17 years ago
|
||
Comment on attachment 285547 [details] [diff] [review] updated patch need approval for this mostly-debug code to help us track down a mysterious crasher
Attachment #285547 -
Flags: approval1.9?
Assignee | ||
Comment 21•17 years ago
|
||
Reopening since it's clearly still happening to some people
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 22•17 years ago
|
||
Comment on attachment 282343 [details] [diff] [review] debugging code Resetting all approval1.9+ flags on bugs that have not been checked in by Oct 22 11:59 PM PDT. Please re-request approval if needed.
Attachment #282343 -
Flags: approval1.9+
Comment 23•17 years ago
|
||
Comment on attachment 282343 [details] [diff] [review] debugging code This was checked-in as rev 1.5 on 2007-09-30 14:34.
Attachment #282343 -
Flags: approval1.9?
Comment 24•17 years ago
|
||
Comment on attachment 282343 [details] [diff] [review] debugging code Reset approval flag to + as it was already checked in.
Attachment #282343 -
Flags: approval1.9? → approval1.9+
Comment 25•17 years ago
|
||
Related to bug 398084?
Assignee | ||
Comment 26•17 years ago
|
||
I don't think so, unless there's a bug in nsExpirationTracker itself, in which case I think we'd see more crashes and some crashes in gfxTextRunCache which uses it heavily.
Updated•17 years ago
|
Attachment #285547 -
Flags: approval1.9? → approval1.9+
Updated•17 years ago
|
Whiteboard: [needs landing]
Comment 27•17 years ago
|
||
"updated patch" checked-in. Checking in docshell/shistory/src/nsSHEntry.cpp; /cvsroot/mozilla/docshell/shistory/src/nsSHEntry.cpp,v <-- nsSHEntry.cpp new revision: 1.61; previous revision: 1.60 done
Whiteboard: [needs landing]
Comment 28•17 years ago
|
||
The first few crashers due to that check-in are showing up on Socorro: See for example http://crash-stats.mozilla.com/report/index/6ea8c700-8fbd-11dc-be7b-001a4bd43e5c or http://crash-stats.mozilla.com/report/index/21871ab3-8fb6-11dc-b3ee-001a4bd43ef6 (or in general search for nsSHEntry::SetContentViewer).
Assignee | ||
Comment 29•17 years ago
|
||
I think we're violating this: nsSHEntry::SetContentViewer(nsIContentViewer *aViewer) { NS_PRECONDITION(!aViewer || !mContentViewer, "SHEntry already contains viewer"); Not sure how, and with no steps to reproduce, debugging is hard. This patch mitigates this situation somewhat by calling DropPresentationState in that situation. This might save people from crashing.
Attachment #288252 -
Flags: superreview?(bzbarsky)
Attachment #288252 -
Flags: review?(bzbarsky)
Comment 30•17 years ago
|
||
Comment on attachment 288252 [details] [diff] [review] band-aid Let's hope Jesse hits those asserts...
Attachment #288252 -
Flags: superreview?(bzbarsky)
Attachment #288252 -
Flags: superreview+
Attachment #288252 -
Flags: review?(bzbarsky)
Attachment #288252 -
Flags: review+
Assignee | ||
Updated•17 years ago
|
Attachment #288252 -
Flags: approval1.9?
Updated•17 years ago
|
Attachment #288252 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Comment 31•17 years ago
|
||
checked that patch in.
Comment 32•16 years ago
|
||
If I searched the crash reports database correctly, there were lots of crashes with 3.0b1 (2007110904), only one more crash with 3.0b2 (build id 2007121100), and none at all afterwards. So this is fixed?
Comment 33•16 years ago
|
||
Per the last patch, the crash-on-purpose lines have been taken out, so I suspect this bug is being kept open in case someone hits the assert.
Assignee | ||
Comment 34•16 years ago
|
||
I don't think it makes sense to leave bugs open forever "just in case". Let's close this and mark it WFM. We can always open a new bug.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•