u540257 Reporter
	Description • 9 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

Go to www.flickr.com, pick any member and start to browse their photo stream. 
Advance to the next image by clicking ">" or hit the "right arrow" button. 
Continue this way.


Actual results:

In Windows taskmgr you can see Firefox memory going up and up until ~3 GB. 
Then Firefox does not respond anymore.


Expected results:

No hang due to memory overrun. IE11 and Google Chrome do not have this problem.

I use Flickr daily to follow my ~200 contacts which is a rather small number, and I experience the above issue at least 2-3 times a day. Which is really annoying.

This problem relates to Firefox for Windows.
Observed already in 38.0, no change until 42.0
No change also for 42.0 x64.
The problem does not relate to ESR version (currently 38.4.0)

	Valentin Gosu [:valentin] (he/him)
	Comment 1 • 9 years ago

Hi Karsten,
I am unable to reproduce the issue. Could you tell me through how many pictures do you have to go until it stops responding?
Also, would you mind trying this with addons disabled?
If you can still reproduce it, before you hit the memory limit, could you go to about:memory , save a memory report and attach it to this bug?

It would be very helpful. Thanks!

	u540257 Reporter
	Comment 2 • 9 years ago

Hi Valentin,
sorry for the delay - it's been a very busy week for me.
I am able to reproduce the problem also with addons disabled (Firefox started in Safe Mode).
In order to combine work with pleasure, you can go to my photostream and start browsing :-)

https://www.flickr.com/photos/111498703@N07/22584349553

Over here, I am starting with 280K of memory, and I am hitting 1G already after 32 images.

Attached is a memory report I pulled at 2.5G memory consumption.

Hope this helps to pinpoint the cause of this issue!

	u540257 Reporter
	Comment 3 • 9 years ago

Memory report of situation where Firefox has reached 2.5G memory consumption when browsing through Flickr images.

	u540257 Reporter
	Comment 4 • 8 years ago

(In reply to Valentin Gosu [:valentin] from comment #1)
> Hi Karsten,
> I am unable to reproduce the issue. Could you tell me through how many
> pictures do you have to go until it stops responding?
> Also, would you mind trying this with addons disabled?
> If you can still reproduce it, before you hit the memory limit, could you go
> to about:memory , save a memory report and attach it to this bug?
> 
> It would be very helpful. Thanks!

Hi Valentin,

I have added the requested information few weeks back. 
Is that sufficient for you to proceed with your analysis?
If you need anything else pls let me know.
BTW, same problem also in v43 (which is no surprise to me).

	Valentin Gosu [:valentin] (he/him)
	Comment 5 • 8 years ago

Thanks for the memory report. I have been able to reproduce the bug, although not consistently. Memory use seems to grow slowly, and not be released, even when the tabs are closed.

The dump seems to be indicating a problem somewhere that doesn't do memory reporting.
Seth, do you think this could be related to the image caching? Would you mind taking a look?

	Timothy Nikkel (:tnikkel)
	Comment 6 • 8 years ago

I reproduced increasing memory usage, but heap-unclassified stayed reasonable.

├──459.05 MB (45.19%) -- top(https://www.flickr.com/photos/111498703@N07/17194743099/in/photostream/, id=31)
│  ├──375.96 MB (37.01%) -- active/window(https://www.flickr.com/photos/111498703@N07/17194743099/in/photostream/)
│  │  ├──185.76 MB (18.29%) ++ js-compartment(https://www.flickr.com/photos/111498703@N07/22584349553)
│  │  ├──174.03 MB (17.13%) -- dom
│  │  │  ├──172.05 MB (16.94%) ── orphan-nodes
│  │  │  └────1.98 MB (00.19%) ++ (5 tiny)
│  │  └───16.16 MB (01.59%) ++ (3 tiny)
│  └───83.09 MB (08.18%) ++ js-zone(0x12fc08000)

The js stuff gets rather large, can't say if that is reasonable or not. orphan-nodes catches my eye though. Seems like the page is keeping around a lot of references to nodes that aren't in the document.

├────215.74 MB (21.24%) -- images
│    ├──210.38 MB (20.71%) -- content/raster/used
│    │  ├──197.65 MB (19.46%) -- (1074 tiny)
│    │  │  ├────4.56 MB (00.45%) -- image(304x3664, https://s.yimg.com/uy/build/images/icons/icons-2x-s14136ff1df.png)
│    │  │  │    ├──4.25 MB (00.42%) ++ locked/surface(304x3664@0)
│    │  │  │    └──0.31 MB (00.03%) ── source
│    │  │  ├────3.97 MB (00.39%) -- image(1200x1600, https://c1.staticflickr.com/9/8724/17194743099_cb4b3f2eb2_h.jpg)
│    │  │  │    ├──3.16 MB (00.31%) ++ locked/surface(788x1050@0)
│    │  │  │    └──0.81 MB (00.08%) ── source
│    │  │  ├────2.35 MB (00.23%) ── image(2048x1365, https://c1.staticflickr.com/1/775/22588085702_9cb037fa14_k.jpg)/source
│    │  │  ├────1.76 MB (00.17%) ── image(1600x1200, https://c1.staticflickr.com/1/720/22108924649_5effa32bd5_h.jpg)/source
│    │  │  ├────1.75 MB (00.17%) ── image(2048x1365, https://c2.staticflickr.com/6/5771/22548916061_64977d6c7f_k.jpg)/source

Under images we have two decoded images that take any significant amount of space, and a ton of non-decoded images (we are just keeping the compressed source around). They are under "used" which indicates there is still a image observer reference to them. This makes me think the orphan nodes are the dom elements for the images, and they are keeping around the compressed source as well.

This indicates that perhaps the page should not be keeping around so many of these nodes.