TS Reporter
	Description • 13 years ago

User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110614 Firefox/3.6.18
Build ID: 20110614230723

Steps to reproduce:

Upgraded to Firefox 4 on Windows and tried to watch my IP cam. I just tried it again on Ubuntu 10 with Firefox 6.0.


Actual results:

On Windows, Firefox was consuming an increasing amount of memory till it crashed. On Ubuntu it caused Firefox and Xorg to use a lot of cpu and memory. I stopped it before a crash happened but I think it was swapping to disk already.


Expected results:

It should just display the changing image like it does with Firefox 3.6.
The cam is SKU 15974 from dealextreme.

	TS Reporter
	Comment 1 • 13 years ago

Duh. I found the problem. It is the noscript plugin.
I started safe-mode and did not see increasing memory usage anymore. I enabled my extensions one-by-one and got my problems back as soon as I enabled noscript :(
This is the tested the same with Firefox 4.0.1 on Windows XP and Firefox 6 on Ubuntu.

	Giorgio Maone [:ma1]
	Comment 2 • 13 years ago

I cannot reproduce using your file (Fx 6 + NoScript 2.1.2.8rc1 from http://noscript.net/getit#devel ).
Maybe an extensions *conflict*? 
Did you actually try on a clean profile with just NoScript installed?
Which rate does the RAM eating happens at?

	TS Reporter
	Comment 3 • 13 years ago

I have a VirtualBox image with XP with 384MB and Firefox 3.6.18. I made a new snapshot and did an upgrade to 6.0. Installed NoScript 2.1.2.8rc1 and restarted Firefox. NoScript is the only extension enabled. Java Console and Java Quickstart are disabled and no other add-ons installed at all on this image.

I double click on viwx.html and select NoScript 'allow file://' to start showing the image.
I have Process Explorer from sysinternals.com running showing the Virtual Size of each process. Before allowing the script to run Firefox uses about 120-160MB.
Most of the time it starts eating >10MB per second right away. As soon as I close the tab the memory usage goes back to 170MB.

Sometimes it stays at 130MB and I need to open a few other pages first before the memory eating kicks in. And sometimes the memory usage is jumping up and down instead of only going up. I guess it depends on how fast your system is. The Ubuntu system I tried is an old D600 with 512MB and there I did see Xorg growing quite a bit (xterm with top running).

It kind of feels like a garbage collector that can not keep up with the allocation of new memory.

	Giorgio Maone [:ma1]
	Comment 4 • 13 years ago

Managed to reproduce on a clean profile after registering a dummy web progress listener on the document loading service.

It seems a Gecko bug causing useless images to be retained longer than usual, and possibly leading to out of memory errors if many images are loaded in rapid sequence by JavaScript. Notice that this work also with inline HTML images, and there's no need to create multiple JavaScript Image objects or even use JavaScript Image objects at all, so it doesn't seem a JavaScript garbage collection issue after all, but rather a memory image caching one.

About to attach a contrived test case.