Open Bug 1167357 Opened 9 years ago Updated 9 months ago

Repeatedly reloading a page with a large noncacheable image eventually causes a decode failure

Categories

(Core :: Graphics: ImageLib, defect, P3)

defect

Tracking

()

People

(Reporter: seth, Unassigned)

References

Details

(Whiteboard: [gfx-noted])

This may be a mobile-only issue. I wasn't able to reproduce on OS X.

STR from bug 1142294 comment 9:

The image doesn't succesfuly load even on 3 GB RAM.
Samsung Galaxy Tab S 10.5, Android 5.0.2, debloated (so more free RAM than by default)

1. Copy the link to the HTML page I attached.
2. Open Firefox and paste & go the URL.
3. The image is shown.
4. Reload the page (sometimes it works the second time, sometimes you need to refresh multiple times).
5. After 1..* reloads, the image is not loaded anymore (like on low memory devices, but this one has 3 GB).

This is reproducible with other images as well.
For the images to load again, I have to force stop Firefox.
Whiteboard: [gfx-noted]
Seth's comment from bug 1142294:

That image requires 278MB of memory to display. It's being loaded with the HTTP header "Cache-Control: max-age=0", which as currently implemented in Firefox causes us to treat the image cache entry as stale and decode a new copy of the image. The old copy will stick around for a while, until the cache decides to evict it, so memory usage grows by ~278MB every time you reload the page.

That's actually all expected! What is unexpected is that this additional memory usage seems to be causing us to eventually fail to allocate a texture for the image. What should be happening is that when you get to the point where you don't have enough memory to allocate the next texture, we should discard old, unused textures until we have enough memory. So what you're doing should never cause an allocation failure.
I tried clearing the cache from the privacy options menu, and GC-ing everything from about:memory, but the problem still persists until I close Firefox for good.
Assignee: nobody → droeh
Is this problem a general one(In reply to Nicolae Albu from comment #1)
> Seth's comment from bug 1142294:
> 
> That image requires 278MB of memory to display. It's being loaded with the
> HTTP header "Cache-Control: max-age=0", which as currently implemented in
> Firefox causes us to treat the image cache entry as stale and decode a new
> copy of the image. The old copy will stick around for a while, until the
> cache decides to evict it, so memory usage grows by ~278MB every time you
> reload the page.
> 
> That's actually all expected! What is unexpected is that this additional
> memory usage seems to be causing us to eventually fail to allocate a texture
> for the image. What should be happening is that when you get to the point
> where you don't have enough memory to allocate the next texture, we should
> discard old, unused textures until we have enough memory. So what you're
> doing should never cause an allocation failure.

Is this problem a general one? Because I encounter it only on Android 5.0.2.
I have a tablet with 5.0.2 and a phone with 4.4.2.
Browsing in the same way, after I load some large images, on 5.0.2 large images won't load anymore, but small ones do. On 4.4.2 this never happens.
Flags: needinfo?(seth)

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: droeh → nobody

Redirect a needinfo that is pending on an inactive user to the triage owner.
:aosmond, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(seth.bugzilla) → needinfo?(aosmond)
Severity: normal → S3
Flags: needinfo?(aosmond)
You need to log in before you can comment on or make changes to this bug.