png image memory leak

[Crimson]

Before I go into the memory leak, here is a quick list of all the things I tried to resolve it without success:
- Disabling and removing extensions
- Changing and trying various settings and about:config entries (such as disabling all caching)
- Creating new profiles and testing with default and changed settings
- Using private browsing or starting in safe mode
- Using the portable exe version
- Deleting all profiles then reinstalling and retrying the above points
- Testing the 32bit version

Which suggests that profile settings or extensions aren't the culprit.

To quickly demonstrate the leak I've chosen the following site since it contains quite a few small pngs: https://ehwiki.org/wiki/Spells
Expectation: Everything works as usual.
Reality: heap-unclassified increases by over 30MB and won't ever release that memory. One thing worth pointing out is that loading the page (and optionally waiting for a bit) only causes heap-unclassified to go up by a smaller amount, only when you scroll down through the pictures does it take the aforementioned over 30MB.

Some points:
- Disabling or blocking non-images like css or js appears to do nothing about the leak, while doing the same for images or just png files completely prevents it.
- Other image files such as jpg do not cause the memory leak.
- I've been having this issue for quite a long time so it's not something recent, though I can't say when it started or if it was always the case. I initially thought it was just a website error/incompatibility since it only really affected one site I was using palemoon for, so I didn't give it a closer look. But since I now want to use palemoon exclusively and started using various other sites I looked deeper into it and here I am.
- All tests were done with Windows 8.1 pro 64bit and the newest exe versions.

This is all I got. Can anyone confirm that it doesn't just happen on my end?
Thanks in advance.

[Moonchild]

I've been trying to reproduce this and I can't.
heap-unclassified (listed under main process) remains about the same (just under 60MB total) when performing the STR. Of course the various graphics memory measurements go up because the images are cached in various states for performance reasons.

Does this memory increase happen every time you visit the page or just once? If it's just once, then it's not a leak and likely just an unmeasured/uncategorized allocation of internal structures. A leak would mean you'd have allocations constantly increasing with repeat similar actions -- "not deallocating something" by itself is not a leak.
Are you really worried about the browser measuring 30MB of memory allocation not specifically classified under something?

[Crimson]

Thanks for the quick reply.

It happens every time a png file gets requested, so not just on the site I listed. So it can get big quickly on png heavy sites. The biggest one I had was about 1GB before I restarted.
But if you can't recreate it then it means it's something on my end. Just wanted to make sure if others also have this issue.
I'm going to look into my system and check if there's anything corrupted then do a clean install again and see if it fixes it.

[Moonchild]

Please be aware that if you aren't hurting for memory, then depending on your use/sites visited, the browser may use up to 1 GB for its surface cache which might be listed as heap-unclassified.

[Crimson]

I was able to fix the issue.
Setting gfx.color_management.enablev4 to false prevents the memory leak.
Setting it back to true causes the leak to happen again so it's definitely the cause.

[Moonchild]

I see. Looks like there's a leak in qcms then. Unfortunately that's not native code, it's C and seems to be mostly unmaintained at this point
We might have to disable ICCv4 color correction by default to prevent this leak.

[therube]

Not that I know what I'm looking for...

about:memory, Measure, check for heap-unclassified
load, https://ehwiki.org/wiki/Spells
use linked images to open the images, again
https://www.squarefree.com/bookmarklets ... ked_images
about:memory, Measure, check for heap-unclassified
note the (on my end) small increase in HU
load, https://www.yahoo.com
about:memory, Measure, check for heap-unclassified
note the (on my end) small increase in HU
close the (2) https://ehwiki.org pages
about:memory, Measure, check for heap-unclassified
note the decrease increase in HU
...


note that default is true for, gfx.color_management.enablev4


On my end, whether true or false does not seem to make any (meaningful) difference.
(Restart PM after toggling, assuming it is probably needed for that Pref?)

So... thinking that OS, video card, drivers may also be playing in?

Win7 x64, Intel HD 4000 graphics (built-in, on CPU)

[vannilla]

I see. Looks like there's a leak in qcms then. Unfortunately that's not native code, it's C and seems to be mostly unmaintained at this point
We might have to disable ICCv4 color correction by default to prevent this leak.

lcms seems to be still maintained, the last commit was 10 days ago.
According to the website it fully supports ICCv4.
Would it be possible to switch to it? Even just to use a still-maintained CMS.

[Moonchild]

lcms has actually originally been the CMS used by Mozilla. When they swapped to qcms, people were complaining about the lack of ICCv4 support in it. Since speed is much less of a concern on modern hardware since that decision, and lcms seems to be a lot more robust in handling ICC profiles, it's a good suggestion. Issue #1363 (UXP)