Closed
Bug 23263
Opened 25 years ago
Closed 24 years ago
memory cache shutdown assertion failure
Categories
(Core :: Networking: Cache, defect, P3)
Core
Networking: Cache
Tracking
()
VERIFIED
FIXED
M15
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.
Updated•25 years ago
|
Assignee: gagan → gordon
Target Milestone: M14
Comment 1•25 years ago
|
||
-> gordon
Comment 2•25 years ago
|
||
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.
This doesn't look like it's Windows specific. Changing platform to ALL.
Comment 4•25 years ago
|
||
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.
Updated•25 years ago
|
Summary: memory cache shutdown assertion failure → [MLK] memory cache shutdown assertion failure
Comment 6•25 years ago
|
||
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.
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.
Updated•25 years ago
|
Summary: [MLK] memory cache shutdown assertion failure → memory cache shutdown assertion failure
Updated•25 years ago
|
Target Milestone: M14 → M15
Comment 8•25 years ago
|
||
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
Comment 9•24 years ago
|
||
Ruslan's on top of this one now.
Assignee: gordon → ruslan
Status: ASSIGNED → NEW
Assignee | ||
Comment 10•24 years ago
|
||
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
Comment 11•24 years ago
|
||
*** Bug 33631 has been marked as a duplicate of this bug. ***
Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•