This is a problem I've found by code inspection, but I've never been able to cause it to happen in running code. Its nature is such that it could cause bug 480352; if it does fix that problem, though, I have no clue how the patch from bug 466586 could have caused it, nor why it'd only show up on Windows (at least on crash-stats). If an image load comes in on one page (or on one thread) for an image that's already being loaded on a different page (or on a different thread), we correctly don't cache the second load, and let it load all by its lonesome. However, the second imgRequest still thinks it's cached, and will ask the image cache to remove itself when it's cancelled, etc. The problem is that the cache can't easily tell the difference between duplicate imgCacheEntries/imgRequests for the same URL. I will have to think hard about how to test this. As I mentioned, I've never seen this happen.

http://hg.mozilla.org/mozilla-central/rev/dc3e1ab79397 Fingers crossed...

This case (same image requested by multiple pages) does in fact get hit. Write a test for this, perhaps? It doesn't seem like it should be that hard with a page and an iframe... Do we need this on 1.9.1?

I slightly misread the code. This patch only fixes the case of loading from a different thread; in that case, it was possible for the problem described to happen. So, only if we're in the middle of loading on one thread, and then on a different thread, try to load the same image. I don't know that this is actually possible, though.

Shouldn't be. All loads happen on the main thread.

Stuart, why was there all that thread machinery in the image cache to begin with, then?

Stuart tells me the thread stuff is in imglib for the ability to decode on different threads, which we don't do right now.