Closed Bug 538698 Opened 14 years ago Closed 14 years ago

crash [@nsCacheService::DoomEntry_Internal(nsCacheEntry*)] on shutdown

Categories

(Core :: Networking: Cache, defect)

defect
Not set
critical

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)

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.
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
Attached patch match guardsSplinter Review
Assignee: nobody → timeless
Status: NEW → ASSIGNED
Attachment #420894 - Flags: review?(cbiesinger)
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 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
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
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...)
This has been on trunk for three months. It would help us if it can be on FF 3.6.
blocking1.9.2: --- → ?
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?
? What is an approval request?
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 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+
blocking1.9.2: ? → -
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.
Removing the 1.9.2.9-fixed flag.
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.
Blocks: 591647
No, it means that the bug is fixed in that particular branch.
blocking1.9.2: - → ?
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: ? → ---
this bug is about something resembling a null pointer crash. bug 591647 is not a null pointer crash.
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.
jjb: that should go in bug 591647
Crash Signature: [@nsCacheService::DoomEntry_Internal(nsCacheEntry*)]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: