211111 - Apparent memory leak, probably while javascript refreshed image is running (webcam)

Status: RESOLVED DUPLICATE of bug 205893

(SeaMonkey :: General, defect)

Description

[griffon4]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

Since 1.4 RC1(used RC2 as well and currently running RC3), Moz memory resources
have been bloating to the point of system crash when I run a javascripted
webcam.  Left the javacam running over the weekend (only Moz component open,
only program active) and by Monday W2K Task manager was reporting approx
111,912K in memory usage (and climbing), and 203,528K at peak memory with
632,580 VM size.

Reproducable: Always

Attached screen prints of desktop: #1 is the Processes tab, #2 is the
Performance tab after I closed the Moz window; the drop off is from the window
closing.


Reproducible: Always

Steps to Reproduce:
1.  http://members.cox.net/griffon/thefield/field.htm
2.  Watch as Moz growz
3.

Actual Results:  
over time (overnight, over a weekend), Moz memory usage gets larger, with
occasional back offs (only to build again).

Expected Results:  
Remained at a fairly constant memory usage.

I had this problem both before and AFTER a fresh reinstall of my Operating
System, so I'm ruling out something tainted in the water supply.

Comment 1

[griffon4]

Attachment: Screenshot of Task manager and window running

This is the screen shot of what I saw when I came in this morning.

Comment 2

[griffon4]

Attachment: Screenshot after I closed the Moz window

Took a screen shot of the performance tab after I closed the window.  The
severe drop off of memory was Moz closing.

Comment 3

[Hermann Schwab]

Please have a look at 
Bug 203667 GDI objects overflow (Win) and X11 server size increase (Linux) when
reloading images by javascript

Comment 4

[griffon4]

Read the bug; looks similar but the only thing that troubles me is that he was
worksforme at RC2.  I'm at RC3 and still having the problem.

I have lowered the Cache to 10MB and will experiment with turning the image
cache off in about:config

Comment 5

[Boris Zbarsky [:bzbarsky]]

Actually, this was probably fixed by bug 199443 (which did not make it into
1.4rc3 as far as I can tell...)

Comment 6

[griffon4]

I disagree: I am using RC3, both before and after the OS reinstall.

I have held off filing a bug report about this because I didn't want to file a
dup or something that was just "my problem".  But after messing with this for 3
releases and an OS reinstall (over a period of two weeks), I am convinced there
is something here.

I have turned off the cache and will let it run overnight and see what happens.

Comment 7

[beanladen]

Please read carefully: Boris wrote it did NOT make it into rc3...
So you don't have the fix.

Comment 8

[griffon4]

My bad.  Sorry!

Comment 9

[griffon4]

I am writing in to report my experiences with the new 1.4 (RC3 uninstalled and
1.4 freshly installed yesterday).  At the end of a normal browsing day Mozilla
sat with a Mem Usage of 70,424K, Peak of 82,884K and VM Size of 161,008K (GDI
objects were 514).  I left the javascript webcam running overnight and came in
this morning with a Mem Usage of 136,820K, Peak of 168,112K, and VM Size of
370,028K (GDI was 528).  

So what gives?  If there isn't a bug, how do memory resources double overnight
for a window running a javascript image refresh?

When I turned off the browser.cache.memory.enable the day before, the resources
didn't change appreciably.  With it turned back on, it eats memory.

No crashes so far; but is this normal behavoir?

Comment 10

[Jim Dunn]

Yeah this problem seems similar to the others.
We (in the image cache) are storing each *shot* using its url
(which has a timestamp).  So each *shot* is unique and will
be stored in the cache, filling the cache.  With each entry
we also have a GDI handle (see bug 205893) and so eventually
we will fill up our cache at which time, THEN we will start
recycling gdi handles.  If memory cache is very large we will
probably run the system out of resources before we fill the
cache.  My patch for bug 205893, limits the GDI objects that
we hold to 100 so should get us past this bug.

so right now am assuming this is a dup of bug 205893

Comment 11

[griffon4]

I'm in.  I'm all for filing this as a dupe.  Once the fix is in place, I'll run
the same scenario and make sure it's fixed.

Thanks for the attention to my little bug! 

Comment 12

[Jon Henry]

Per griffon and Jim's comments, I am going to mark this as a dupe of bug 205893.
If the fix for that bug turns out not to help, please reopen for more
investigation. Thanks.

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