112158 - memoryusage goes sky-high displaying page with webcams

Status: RESOLVED DUPLICATE of bug 179498

(Core :: Graphics: ImageLib, defect)

Description

[Mrten]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.6+) Gecko/20011126
BuildID:    2001112603

This particular URL is a collection of webcams that consumes quite a lot of
memory when displayed with mozilla. The memoryusage goes from 30 megs, slowly up
to 270 megs(!), and falls back to about 31. Then this process repeats itself as
long as mozilla is displaying the page. In the Task Manager this makes for a
nice sawtooth in the memoryusage-history :)

I noticed that, when I opened a new window either by Ctrl-N or a bookmark, that
the memoryusage fell back to 31 again.

i asked someone using 2001112012 on linux, the first problem occurs there as
well (up to about 200 meg), but the second phenomonon does not.

incidently, Mozilla eats about 30% of my processorcapacity to display this URL
as well.



Reproducible: Always
Steps to Reproduce:
go to url
watch the memoryusage fly to the sky

Expected Results:  use less memory :)

NT6a+hotfix, have 384 megs of RAM in PC.

Comment 1

[Mrten]

be gentle on that URL plz, the traffic is too high already :)

Comment 2

[Karl Johan Kleist]

Build ID: 2001 11 26 03. Windows 2000.

I can confirm the "sawtooth" pattern. Mozilla sucks c:a 1 MB / second,
up to c:a 200 MB maximum.

But with fourteen webcams in one page, what should we expect?
After all, memory is released now and then...

Comment 3

[Matthias Versen [:Matti]]

-> Imagelib

Comment 4

[Mark Bergsma]

Svante: Yes, but I have seen this occuring with single webcam pages as well,
although a bit slower. It does not pose a problem for me now, with 512 megs of
mem, but it did crash (and trash) Mozilla and sometimes even X (Linux) back when
I had 128 MB installed.

Comment 5

[Mrten]

moved to imagelib, as matti suggested.

I expect that, even with 14 webcams on the page, memory is allocated when it is
necessary and released when the necessity to keep it allocated is no more.

the allocation of 270 megs of memory seems a bit overkill to me.

i noticed that javascript is used, which may have to do with this (a too-long
deferred garbage collect?)

memoryusage ups with about 1 M/s, while the images stream in at about 70K/s. i
collected all images (145 K), and converted them to uncompressed .bmp's, which
gave me about 2 megs of data. the images are reloaded once every 2 seconds, so i
guess all the memory consists of (old!) decoded images.

Comment 6

[timeless]

what do nc4 and ieX do?

Comment 7

[Mrten]

NS4.7 strays around 10 meg of memusage, IEx i do not have.

Comment 8

[Sitsofe Wheeler]

The url (http://www.sneeuwhut.com/webcam.php) no longer exists. Reporter
(Mrten), can you point us to another page that shows this problem?

Comment 9

[Mrten]

here is a new URL i created to test for this bug.

Comment 10

[Mrten]

i forgot to reassign....

Comment 11

[Phil Schwartau]

AFAIK, memory management issues like this are best dealt with
in the component closest to what is happening, not the JS Engine. 

Back to ImageLib -

Comment 12

[Boris 'pi' Piwinger]

Is this still an issue in a current build?

pi

Comment 13

[Adam Hauner]

Mrten, http://famke.gimmie.tudelft.nl/mrten/moz/cam.html is 'File Not Found'.
Could you provide actual URL for testcase?

Comment 14

[Mrten]

apologies, re-installed my server and forgot a few thingies :)

just tested, it still happens, but the effect is not as pronounced as before. it
sawtooths with an amplitude of 60 megs now.

Comment 15

[Boris 'pi' Piwinger]

Well, using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020527 I
see it go a bit slower, but not that bad. An expert should look at it. Reducing
Severity, but NEW.

pi

Comment 16

[Jo Hermans]

Reporter, is this still a valid bug ? Mozilla 1.3 has improved memory usage for
images (killing a huge memory leak).

Comment 17

[Mrten]

nope, does not seem to be a problem anymore. 
do you happen to know the bug# of that memory-leak-fix?

Comment 18

[Jo Hermans]

bug 179498

Comment 19

[Mrten]

*** This bug has been marked as a duplicate of 179498 ***