1153062 - Very high memory usage when very large images are displayed

Status: UNCONFIRMED

(Core :: Graphics: ImageLib, defect)

Description

[Brian Wong]

Related to https://bugzilla.mozilla.org/show_bug.cgi?id=692781  but is not specific to Linux or X11. The linked bug also has not been updated in a long time.

When loading and displaying a very large image (40-50 megapixels or larger) in Firefox, such as http://www.samsung.com/global/business/semiconductor/file/news/28-mp1.jpg, memory usage can become very high (300+ MB to more than a gigabyte), and the browser may hang. The increased memory usage may be momentary or persistent, and occurs primarily when the image is actually displayed (i.e. the tab containing the image is selected). In some cases, such as when multiple such large images are present in a page (e.g. http://www.samsung.com/global/business/semiconductor/news-events/press-releases/detail?newsId=13683), the browser could crash altogether.

The issue reproduces in both Firefox 37 and Firefox Developer Edition 39.

Comment 1

[Timothy Nikkel (:tnikkel)]

A 50 megapixel image requires 50*4 bytes = 200MB just to hold the decoded image data. So 300mb seems quite reasonable for Firefox to take. When an image is not display (scrolled far out of view, in a background tab) we try to discard the decoded image data to save memory.

For pages like the one you linked to where they display a gigantic image resized to a very small size we have work underway to only store a small copy of the image.

Are you seeing any examples where the above information wouldn't explain the memory use you are seeing?

Comment 2

[Brian Wong]

Neither Internet Explorer nor Windows Photo Viewer use this much memory when displaying such a large image. Furthermore, memory usage ranging from 400 MB to 650 MB has been observed when displaying the standalone image linked above, with peak usage potentially exceeding 1.2 GB while rendering the image. This memory usage can sometimes be persistent, possibly due to inconsistent GC/CC behavior—this is how Firefox once crashed while rendering the linked page. Hitting "Minimize memory usage" in about:memory clears it up, but memory usage will spike again when the image is displayed afterwards.

Comment 3

[Timothy Nikkel (:tnikkel)]

If you reproduce a situation where you feel Firefox is using significantly more memory then (image size in megapixels) * 4 bytes for each image then goto about:memory and save a report.

Comment 4

[Seth Fowler [:seth] [:s2h]]

The symptom of excessive memory usage when viewing the image standalone remind me very much of bug 1119455. We have some buggy behavior with favicons that can cause us to load them more than once, even if we should have them cached, and decode multiple copies of them. That's extra problematic in this case because the favicon of an image document is the image itself, so we may load and decode multiple copies of this huge 50MP image.

Unfortunately I can't get the image to load right now, so I can't confirm this, but I'll try again another time.

Brian, if you can get an about:memory report that captures the excessive memory usage, as Timothy suggests in comment 3, that would help confirm whether the favicon issue is the cause.

Comment 5

[Brian Wong]

I can't capture the peak usage in a JSON report, but I was able to save a copy of the about:memory page showing 600 MB of memory use while rendering the image from cache. See attachment.

Comment 6

[Brian Wong]

Attachment: Copy of memory report captured while rendering the standalone image.

Comment 7

[Brian Wong]

Attachment: about memory (live measurement)_files.zip

Comment 8

[Brian Wong]

If you're concerned, I've examined the page and found small pieces of somewhat personal information (most significantly a few previously-visited URLs) but it's no big deal; it's stuff I'm not presently interested in and don't really care about. The report reflects Firefox Developer Edition 39.0a2.

Comment 9

[Seth Fowler [:seth] [:s2h]]

Hmm. So in that about:memory report, we're using 242MB for that image, which isn't obviously wrong.

I find it troubling that there's 246MB of heap-unclassified, though. Perhaps it's just a coincidence, but that's pretty close to the decoded size of the image.

We should definitely check into this further and make sure we aren't leaking decoded images somewhere.

Comment 10

[Timothy Nikkel (:tnikkel)]

So I tested on my Linux machine with Firefox 37 and the latest nightly, the results were the same for both versions. In about:memory heap-unclassified goes to about 264mb, and the reported memory for the image is about 5mb.

I remember that on Linux I think images are treated a little different (x11 and pixmaps?). We should do a dmd build to confirm that the heap-unclassified is the image. And then make sure it gets reported properly in about:memory. And then we should figure out why Brian is see two copies of the image, maybe we optimize the image, and then de-optimize it and the pixmap sticks around? But why doesn't it re-optimize again and get rid of the second copy in memory?

Comment 11

[Brian Wong]

One point that has been overlooked is the brief spikes in memory usage while rendering the image. I've observed system reported memory use upwards of 1.2 GB in Task Manager. At times, this memory use is persistent but is not reported by about:memory. Is there some issue with the way memory is allocated and freed?

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

Are all the numbers in this bug related to Linux?  Asking because comment 0 mentions this isn't Linux specific, and platforms shows Windows 8.1.

Comment 13

[Brian Wong]

The issue continues to reproduce under Firefox Developer Edition 47.0a2. I saw a brief memory usage spike in excess of 1 GB in the plugin container before settling down.

Comment 14

[Timothy Nikkel (:tnikkel)]

(In reply to Brian Wong from comment #13)
> The issue continues to reproduce under Firefox Developer Edition 47.0a2. I
> saw a brief memory usage spike in excess of 1 GB in the plugin container
> before settling down.

I couldn't reproduce that. The child process went up to 280mb max for me with e10s. Without e10s we hold onto a full size decoded copy of the image that never seems to go away, but still not 1GB. It's weird that it would differ from e10s to non-e10s.

The memory spike might be caused by decoding a full sized copy of the image, and then determining that we don't need it. But still, that should only be about 250mb.