Closed Bug 23263 Opened 25 years ago Closed 24 years ago

memory cache shutdown assertion failure

Categories

(Core :: Networking: Cache, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bns_robson, Assigned: ruslan)

References

()

Details

(Keywords: memory-leak)

I am running a mozilla built from the 4th Jan 2000 sources

When I look at page http://www.iconics.co.uk/applicat.htm I receive the message

###!!! ASSERTION: Failure to shut down memory cache cleanly. Somewhere, someone
is holding references to at least one cache record: 'NS_SUCCEEDED(rv) &&
(mNumEntries == 0)', file
d:\mozilla_source\mozilla\netwerk\cache\memcache\nsMemCache.cpp, line 56

This page uses javascript to change displayed GIF files when the mouse is moved
over the page.
Assignee: gagan → gordon
Target Milestone: M14
-> gordon
The assertion failing is that a cache entry has a non-zero ref count on
shutdown,
meaning that something is holding on to it (the HTTP channel).  This is no
different
in nature than the other leaked XPCOM objects reported by the bloaty stats - the
cache code is simply more vocal about reporting it - as it should be, since such
cache entries cannot be flushed from memory to make space for new cache content.
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
This doesn't look like it's Windows specific. Changing platform to ALL.
Incidentally, in case it isn't obvious, this bug is not actually a cache bug.
Rather, it's a bug somewhere else that is being reported by the cache code.
Something  is holding onto an HTTP channel (a load group maybe ?), which in turn
is holding on to a cache entry.
*** Bug 24293 has been marked as a duplicate of this bug. ***
Summary: memory cache shutdown assertion failure → [MLK] memory cache shutdown assertion failure
From my comment in bug 24293: "What's happening is that RemoveAll is trying to
delete each cache record, but in nsMemCacheRecord::Delete, mNumChannels is 1 so
it ends up returning NS_ERROR_NOT_AVAILABLE. I don't know why mNumChannels
isn't zero."

So I agree -- this does seem like someone else holding on to an nsHTTPChannel
that's causing the cache shutdown problem.
Keywords: mlk
I looked into this a bit and it appears to only happen when you mouse over the 
icons so that we show the other image. However in the lastest build I have the 
images no longer  change on mouse over in mozilla so I don't get the assert. 
Summary: [MLK] memory cache shutdown assertion failure → memory cache shutdown assertion failure
Target Milestone: M14 → M15
I just had two Assertions in Windows 2000 (retail)when trying to shutdown
Mozilla.  Here is the info:

WEBSHELL- = 4
WEBSHELL- = 3
WEBSHELL- = 2
Shut down app shell component {4a85a5d0-cddd-11d2-b7f6-00805f05ffa5}, rv=0x00000
000
Shut down app shell component {18c2f989-b09f-11d2-bcde-00805f0e1353}, rv=0x00000
000
XXX WARNING: Number of webshells being leaked: 2
~nsProfile
WEBSHELL- = 1


NSPR:EventReceiver: mozilla.exe

The insturction at "0x01e02991" referenced memory at "0xdddddde5", The memory
could not be "read".

The second assert I got the next time I logged in and shut mozilla down.  It
appears a bit different.

WEBSHELL- = 4
WEBSHELL- = 3
Shut down app shell component {4a85a5d0-cddd-11d2-b7f6-00805f05ffa5}, rv=0x00000
000
Shut down app shell component {18c2f989-b09f-11d2-bcde-00805f0e1353}, rv=0x00000
000
XXX WARNING: Number of webshells being leaked: 3
~nsProfile
WEBSHELL- = 2
###!!! ASSERTION: Failure to shut down memory cache cleanly. Somewhere, someone
is holding references to at least one cache record: 'NS_SUCCEEDED(rv) && (mNumEn
tries == 0)', file e:\mozilla\netwerk\cache\memcache\nsMemCache.cpp, line 56
Ruslan's on top of this one now.
Assignee: gordon → ruslan
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
When we get 304 and the transport hasn't timed out yet - we don't process OnStop 
 till then. If you happen to close the browser before the transport times out - 
it'll assert cuz it's still holding onto a channel which is holding onto a cache 
entry.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 33631 has been marked as a duplicate of this bug. ***
verified dup
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.