Closed
Bug 538698
Opened 14 years ago
Closed 14 years ago
crash [@nsCacheService::DoomEntry_Internal(nsCacheEntry*)] on shutdown
Categories
(Core :: Networking: Cache, defect)
Core
Networking: Cache
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a5
Tracking | Status | |
---|---|---|
status1.9.2 | --- | .9-fixed |
People
(Reporter: rcampbell, Assigned: timeless)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
519 bytes,
patch
|
Biesinger
:
review+
christian
:
approval1.9.2.9+
|
Details | Diff | Splinter Review |
seeing crash reports for 3.0.10, 3.0.16, 3.5.5 and 3.6 nightlies with this signature. Not many but a few. Discovered during some Firebug testing on shutdown. Unable to reproduce accurately, but filing this bug as a placeholder for more data.
Updated•14 years ago
|
Component: General → Networking: Cache
Product: Firefox → Core
QA Contact: general → networking.cache
Signature nsCacheService::DoomEntry_Internal(nsCacheEntry*) UUID 9fe96170-291a-476f-b46e-c687f2100109 Time 2010-01-09 07:41:35.23819 Uptime 29417 Last Crash 277556 seconds before submission Product Firefox Version 3.6b5 Build ID 20091204143806 Branch 1.9.2 OS Windows NT OS Version 6.0.6001 Service Pack 1 CPU x86 CPU Info AuthenticAMD family 15 model 104 stepping 2 Crash Reason EXCEPTION_ACCESS_VIOLATION Crash Address 0x1c User Comments Processor Notes Related Bugs Crashing Thread Frame Module Signature [Expand] Source 0 xul.dll nsCacheService::DoomEntry_Internal netwerk/cache/src/nsCacheService.cpp:1471 1 xul.dll nsCacheService::DoomEntry netwerk/cache/src/nsCacheService.cpp:1456 2 xul.dll nsMemoryCacheDevice::EvictEntries netwerk/cache/src/nsMemoryCacheDevice.cpp:461 3 xul.dll nsCacheService::EvictEntriesForClient netwerk/cache/src/nsCacheService.cpp:852 4 xul.dll nsCacheService::EvictEntries netwerk/cache/src/nsCacheService.cpp:945 5 xul.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102 6 xul.dll XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:2721 7 xul.dll XPC_WN_CallMethod js/src/xpconnect/src/xpcwrappednativejsops.cpp:1740 8 js3250.dll js_Invoke js/src/jsinterp.cpp:1361 9 js3250.dll js_Interpret js/src/jsops.cpp:2240 10 js3250.dll js_Invoke js/src/jsinterp.cpp:1369 11 xul.dll nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1696 12 xul.dll nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:570 13 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114 14 xul.dll SharedStub xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141 15 xul.dll nsObserverService::NotifyObservers xpcom/ds/nsObserverService.cpp:182 16 xul.dll nsAppStartup::Quit toolkit/components/startup/src/nsAppStartup.cpp:250 17 xul.dll nsAppStartup::ExitLastWindowClosingSurvivalArea toolkit/components/startup/src/nsAppStartup.cpp:376 18 xul.dll nsAppStartup::Observe toolkit/components/startup/src/nsAppStartup.cpp:487 19 xul.dll nsObserverService::NotifyObservers xpcom/ds/nsObserverService.cpp:182 20 xul.dll nsXULWindow::Destroy xpfe/appshell/src/nsXULWindow.cpp:566 21 xul.dll nsWebShellWindow::Destroy xpfe/appshell/src/nsWebShellWindow.cpp:773 22 xul.dll xul.dll@0x402bfc 23 xul.dll nsWindow::DispatchEvent widget/src/windows/nsWindow.cpp:2919 24 xul.dll nsWindow::DispatchWindowEvent widget/src/windows/nsWindow.cpp:2947 25 xul.dll nsWindow::DispatchStandardEvent widget/src/windows/nsWindow.cpp:2940 26 xul.dll xul.dll@0x42b42f 27 xul.dll nsWindow::WindowProc widget/src/windows/nsWindow.cpp:3541 28 user32.dll InternalCallWinProc 29 @0xf 30 user32.dll UserCallWinProcCheckWow 31 xul.dll nsAutoMonitor::nsAutoMonitor 32 xul.dll nsAutoMonitor::nsAutoMonitor 33 user32.dll UserCallWinProcCheckWow 34 user32.dll _W32ExceptionHandler Frame 34 is scaring me. UUID 2f7c1bfc-9485-402c-98e5-b14ae2100109 Crashing Thread Frame Module Signature [Expand] Source 0 xul.dll nsCacheService::DoomEntry_Internal netwerk/cache/src/nsCacheService.cpp:1471 1 xul.dll nsCacheService::DoomEntry netwerk/cache/src/nsCacheService.cpp:1456 2 xul.dll nsMemoryCacheDevice::EvictEntries netwerk/cache/src/nsMemoryCacheDevice.cpp:461 3 xul.dll xul.dll@0x3c25dd 4 xul.dll nsObserverService::NotifyObservers xpcom/ds/nsObserverService.cpp:182 5 xul.dll nsXREDirProvider::DoShutdown toolkit/xre/nsXREDirProvider.cpp:876 6 xul.dll xul.dll@0x969543 7 mozcrt19.dll __crtLCMapStringA_stat obj-firefox/memory/jemalloc/crtsrc/a_map.c:298 Frame 7 is similarly scary. UUID 6490baa6-9f67-4b43-a459-7099a2100107 Crash Reason EXCEPTION_ACCESS_VIOLATION Crash Address 0x2f0074 Crashing Thread Frame Module Signature [Expand] Source 0 xul.dll nsCacheService::DoomEntry_Internal netwerk/cache/src/nsCacheService.cpp:1471 1 xul.dll AppendUTF16toUTF8 xpcom/string/src/nsReadableUtils.cpp:309 2 xul.dll nsCacheService::OnProfileShutdown netwerk/cache/src/nsCacheService.cpp:1501 3 mozcrt19.dll arena_dalloc obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4227 4 MSCTF.dll CDefaultProfiles::GetDefaultProfile 5 xul.dll nsObserverService::NotifyObservers xpcom/ds/nsObserverService.cpp:182 6 xul.dll nsXREDirProvider::DoShutdown toolkit/xre/nsXREDirProvider.cpp:876 7 @0x51f7ff 8 xul.dll ScopedXPCOMStartup::~ScopedXPCOMStartup toolkit/xre/nsAppRunner.cpp:1030 9 nspr4.dll PR_GetEnv 10 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:3553 This one seems "normal" afaict mCacheDevice is never nulled out. i think that the cache device is assumed to be a service which shouldn't die before cache entries. nsCacheProfilePrefObserver::Observe(nsISupports * subject, } else if (!strcmp("profile-before-change", topic)) { // profile before change nsCacheService::OnProfileShutdown(!strcmp("shutdown-cleanse", nsCacheService::OnProfileShutdown(PRBool cleanse) if (!gService) return; The guard here is not consistent with the conditions under which the code it guards operates: nsCacheService::~nsCacheService() gService = nsnull; If anyone leaks the cacheService, and the observer is used twice, bad things will happen.
Severity: normal → critical
Keywords: crash
Comment 3•14 years ago
|
||
Why does the observer get used twice?
oh, at the moment it's being used once and registered never (in failure cases) in crash two, which is roughly equivalent to being used twice and registered once :) in crash one where there was probably a fatal exception from a third party module which pushed a windows event queue and caused further event processing.
Comment 5•14 years ago
|
||
Comment on attachment 420894 [details] [diff] [review] match guards hm ok then. can you add a comment like "The cache service has been shut down, but someone is still holding a reference to it. Ignore this call."
Attachment #420894 -
Flags: review?(cbiesinger) → review+
Hello, I encountered a crash while visiting www.co2online.de with Firefox 3.6.3 and Firebug 1.5.3. Everything concerning the crash can also be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=556461 The most recent crash report can be found here: http://crash-stats.mozilla.com/report/pending/42ca4296-0482-45dd-9dbc-564872100406 If you need any more information, I'd be glad to help. Regards, Dennis
Comment 8•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/06273602cad6
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a5
Version: unspecified → Trunk
Comment 9•14 years ago
|
||
Is it possible to land this on a Firefox 3.6.X release? (This is killing me, hence my 1 vote for this idea and I suspect I may not be alone...)
Comment 10•14 years ago
|
||
This has been on trunk for three months. It would help us if it can be on FF 3.6.
blocking1.9.2: --- → ?
Assignee | ||
Comment 11•14 years ago
|
||
Comment on attachment 420894 [details] [diff] [review] match guards jjb: please use approval requests, not blocking for such things...
Attachment #420894 -
Flags: approval1.9.2.9?
Comment 12•14 years ago
|
||
? What is an approval request?
Comment 13•14 years ago
|
||
It's a flag on a patch (rather than on a bug) that determines whether the patch can land on a branch. timeless just requested it.
Comment 14•14 years ago
|
||
Comment on attachment 420894 [details] [diff] [review] match guards a=LegNeato for 1.9.2.9. Please land this on mozilla-1.9.2 default.
Attachment #420894 -
Flags: approval1.9.2.9? → approval1.9.2.9+
Comment 15•14 years ago
|
||
Pushed: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/dedd825272e3
status1.9.2:
--- → .9-fixed
Comment 16•14 years ago
|
||
As you can see from eg http://crash-stats.mozilla.com/report/index/bp-57f904b3-c730-410a-99f0-b28052100826 this crash still occurs on 3.6.10pre.
Comment 18•14 years ago
|
||
Will removing that flag change anything? The bug is still FIXED and no other flags indicate anything needs to be done here. I thought that flag only meant the patch landed on 1.9.2 at .9, which is still true.
Comment 19•14 years ago
|
||
No, it means that the bug is fixed in that particular branch.
Comment 20•14 years ago
|
||
I guess we'll go back to calling this 1.9.2.9-fixed to represent something getting checked in since John opened a dupe bug 591647 rather than reopening this one. Which is probably fine since this bug specifies "on shutdown" when lots of people are complaining of a crash at the same place that is definitely not on shutdown (e.g. bug 556461, bug 591647)
blocking1.9.2: ? → ---
status1.9.2:
--- → .9-fixed
Assignee | ||
Comment 21•14 years ago
|
||
this bug is about something resembling a null pointer crash. bug 591647 is not a null pointer crash.
Comment 22•14 years ago
|
||
When I break into MCVC++ at failure point I see if (device) device->DoomEntry(entry); - device 0x00650072 nsCacheDevice * + __vfptr 0x20000000 * The address of the vfptr looks suspicious.
Assignee | ||
Comment 23•14 years ago
|
||
jjb: that should go in bug 591647
Updated•13 years ago
|
Crash Signature: [@nsCacheService::DoomEntry_Internal(nsCacheEntry*)]
You need to log in
before you can comment on or make changes to this bug.
Description
•