Loading the URL above gives: ###!!! ASSERTION: Queue and cache sizes out of sync!: 'queuesize == cachesize', file /Users/bzbarsky/mozilla/debug/mozilla/modules/libpr0n/src/imgLoader.cpp, line 494 In particular, we have: (gdb) frame 5 #5 0x02d46ab3 in imgLoader::VerifyCacheSizes () at /Users/bzbarsky/mozilla/debug/mozilla/modules/libpr0n/src/imgLoader.cpp:494 494 NS_ASSERTION(queuesize == cachesize, "Queue and cache sizes out of sync!"); (gdb) p queuesize $1 = 1 (gdb) p cachesize $2 = 3 (gdb) p sCacheQueue.GetNumElements() $3 = 1 (gdb) p sCache.Count() $4 = 3 (gdb) p sChromeCacheQueue.GetNumElements() $5 = 0 (gdb) p sChromeCache.Count() $6 = 0 Sorry about the lack of minimal-ish testcase...
Probably related is: WARNING: Expired objects were not removed or marked used: file ../../../dist/include/xpcom/nsExpirationTracker.h, line 215
9 years ago
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P3
This looks a lot like it's being caused by bug 89419 -- image requests think they have one URI, but actually have another, so they're removed from the queue on pop, but can't be found in the cache because they don't have the keyed URI.
Hmm. There is indeed a 302 here for a gif (redirecting to http://ds.serving-sys.com/BurstingCachedScripts/Res/Blank_1x1.gif). I get the assert a whole bunch, but that's because after the 302 every single image load (for the rest of the browsing session, even after I leave this page) asserts. Can we at least do something about the latter? ;)
Bug 89419 is fixed, and thus so is this.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
verified FIXED on debug builds: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090706 Minefield/3.6a1pre ID:20090706143743 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:220.127.116.11pre) Gecko/20090706 Shiretoko/3.5.1pre ID:20090706143721
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.