1006295 - Memory leak in Firefox 29 involving highslide.js

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[Nicholas Nethercote [inactive]]

+++ This bug was initially created as a clone of Bug #1005887 +++

From bug 1005887 comment 5:

You can you reproduce it quickly with highslide.js... click the first picture in album, then the "play" button.

http://www.hardwarefreak.com/web/daniel-robert-landreth/gallery/

Watch your fav memory monitor.  You can see the mem consumption jump every 3 seconds when the next image is loaded.  It takes ~5 minutes, ~180 images through the slideshow, to eat all 2GB of RAM on my two Windows XP boxen, at which point the slideshow stops displaying the images, just white, and Windows eventually complains of low memory and attempts to increase the pagefile size.  

I've been using highslide.js for photo albums for many years.  This problem did not exist with FF 28 and earlier, but for one release in the teens, IIRC.  That one introduced the same memory leak problem with highslide.  In that case it was fixed in the subsequent release which arrived pretty soon thereafter, so I never reported it.

Comment 1

[Nicholas Nethercote [inactive]]

Stan, are you able to capture and attach a memory dump via about:memory's "measure and save" button?

Comment 2

[Stan Hoeppner]

Attachment: memory-report.json.gz

Comment 3

[Stan Hoeppner]

(In reply to Nicholas Nethercote [:njn] from comment #1)
> Stan, are you able to capture and attach a memory dump via about:memory's
> "measure and save" button?

Yes.  I stopped the slideshow when Task Manager showed FF using ~1.25 GB of memory and took the measurement, fearing that if I let it run until the system ran out of memory it may not work.  As the problem is cumulative, I assume it should be visible in the dump.  I just attached the memory report.

Comment 4

[Stan Hoeppner]

The bug lists the platform as x86_64 Linux.  I'm seeing the problem on two Win XP 32 bit machines and a Win7 64 bit machine.

Comment 5

[Timothy Nikkel (:tnikkel)]

Probably the same issues as bug 985193. Marking a dependency.

Comment 6

[Stan Hoeppner]

I'm not sure why you changed OS:Linux--> Windows 7, as I clearly stated two WinXP machines and one Win7 machine.  WinXP is my primary FF platform and I discovered the bug there.  I simply confirmed it on two other machines, one being Win7.  Might categorizing this bug as "Platform: x86_64 Windows 7" have unintended consequences, possibly cause developers think down the wrong path(s)?  Shouldn't every confirmed affected OS platform be listed?

Comment 7

[Nicholas Nethercote [inactive]]

> Shouldn't every confirmed affected OS platform be listed?

Bugzilla only allows one selection for the platform. Don't be alarmed, it's not such an important field, and the comments make it clear that XP is affected too.

Comment 8

[Nicholas Nethercote [inactive]]

Thanks for the data. Here are measurements of interest:

> 129.51 MB (100.0%) -- explicit
>    94.96 MB ── heap-allocated
>   518.86 MB ── gfx-surface-win32
> 1,215.77 MB ── private
> 1,220.16 MB ── resident
> 1,399.94 MB ── vsize

Interpretation:

- "explicit" and "heap-allocated" are low, which shows that heap usage isn't
  high. 

- But "private" and "resident" are over 1 GiB, which shows that non-heap usage
  is high. 

- And "gfx-surface-win32" is 518 MiB, showing that gfx memory usage is high; I
  bet the remaining 500+ MiB that is unaccounted for is also being used in some
  fashion related to gfx.

This isn't surprising, given that it's a photo slideshow page that's triggering
the problem.

tn, any idea what be happening here?

Comment 9

[Timothy Nikkel (:tnikkel)]

I think what happens is the images get layerized due to the opacity transition, and that's where things go bad. It's been on my list of things to look at but I haven't gotten to it. The image container we get from RasterImage for layerized images doesn't look like it responds to the usual Discard notifications, so it's lifetime (ie freeing it) would be left to something in layers/gfx to manage and I'm not sure if there is anything does that. So basically it needs more investigation of where the memory is going inside the layers/gfx subsystem.

Comment 10

[Stan Hoeppner]

(In reply to Nicholas Nethercote [:njn] from comment #0)
> +++ This bug was initially created as a clone of Bug #1005887 +++
> 
> From bug 1005887 comment 5:
> ... This problem
> did not exist with FF 28 and earlier, but for one release in the teens,
> IIRC.  That one introduced the same memory leak problem with highslide.  In
> that case it was fixed in the subsequent release which arrived pretty soon
> thereafter, so I never reported it.

I should have stated above that I've seen the out of memory effects due to this problem only with FF 28 and one much earlier version, not when/where the bug does/does not exist, as I do not factually know that to be true.  The underlying problem may or may not have existed all along but I've only triggered the OOM problem a couple of times.  This may be due to the fact that most of my albums have lower resolution photos than the album linked in this bug report, which reproduces the OOM every time.  Lower res and/or fewer photos in those albums may simply not have eaten sufficient memory to trigger the OOM.

Comment 11

[Stan Hoeppner]

(In reply to Stan Hoeppner from comment #10)
> (In reply to Nicholas Nethercote [:njn] from comment #0)
> > +++ This bug was initially created as a clone of Bug #1005887 +++
> > 
> > From bug 1005887 comment 5:
> > ... This problem
> > did not exist with FF 28 and earlier, but for one release in the teens,
> > IIRC.  That one introduced the same memory leak problem with highslide.  In
> > that case it was fixed in the subsequent release which arrived pretty soon
> > thereafter, so I never reported it.
> 
> I should have stated above that I've seen the out of memory effects due to
> this problem only with FF 28 and one much earlier version, not when/where
> the bug does/does not exist, as I do not factually know that to be true. 
> The underlying problem may or may not have existed all along but I've only
> triggered the OOM problem a couple of times.  This may be due to the fact
> that most of my albums have lower resolution photos than the album linked in
> this bug report, which reproduces the OOM every time.  Lower res and/or
> fewer photos in those albums may simply not have eaten sufficient memory to
> trigger the OOM.

Grr, sorry for the typo--just noticed it.  The above should say "problem only with FF 29...", not 28.

Comment 12

[(Away)]

I couldn't reproduce with FF34. Left the slideshow over lunch, came back and memory usage was fine. Stan do you see the same thing?

Comment 13

[(Away)]

> I couldn't reproduce with FF34.
Correction: that test was with my Nightly build from yesterday.

Comment 14

[Stan Hoeppner]

I can't reproduce it with Iceweasel 34 and a 700 photo slide show with high res images.  Looks to be discarding correctly.  Did not test on Windows.

Comment 15

[(Away)]

This one appears to be fixed and 985193 isn't, so unlinking them.