69857 - Motion JPEG network cameras cause memory leakage

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Brian Poole]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0 i686; en-US; 0.8) Gecko/20010222
BuildID:    2001022208

I noticed this on Axis Network cameras' generated webpages, which the
payneconsulting URL is an example of. Search for 'mjpg' on google for other
sites that are open to the public if the payne is full or slow. Basically when
you are viewing the 320x240 motion jpeg mozilla will steadily consumes memory,
eventually causing it to use swap and starve everything else of memory. I'm
pretty sure the effect is the same for the other size 640x480, but that is not
tested. I had a running Mozilla with a mjpg from my own camera (on 10mbit
ethernet) going and when I came back from lunch the mozilla process was using
339M of memory (only limited by the fact that I only have 128M of RAM & 256M of
swap!). Memory is not consumed as rapidly when watching a camera via the
Internet, due to the slower updates I believe, but it is still occuring. There
is javascript in the HTML, so was not sure if this is JS, ImageLib, or what?

This occurs both in the 2001022208 and in the older Mozilla I was using,
20010213. Have not tested it on Windows, only Linux. Will test when I get home.
Netscape 4.76 on Linux does not do this so I believe this is a bug and not just
'what mjpgs do'.

Reproducible: Always
Steps to Reproduce:
1. Load http://www.payneconsulting.com/webcam/ (or an equivalent Axis network
camera served page)
2. Wait, memory will steadily be used, though the amount seems to depend on your
network connectivity. Fast connection -> faster memory usage. You should see
memory usage rise.

Actual Results:  6182 raj 16 0 38968 38M 12756 R 0.0 30.9 2:34 mozilla-bin

This is after 20 minutes of watching the mjpg. Started at around 20M of memory
usage and crept up steadily. As mentioned before, on a faster network connection
I can reproduce this much more quickly, steadily using around 100-160k of memory
in 3-4 seconds. This does not stop at any apparent point and consumes all memory
on the machine.

Expected Results:  Should have not used all of my bloody memory ;)

Well, don't know if it is 'critical' if no one else runs into it (how often are
mjpgs used?) but it is leaking memory and thats what the description of critical
says. G'luck.

Comment 1

[Andreas M. "Clarence" Schneider]

*** Bug 69858 has been marked as a duplicate of this bug. ***

Comment 2

[Brian Poole]

Same thing on Windows/i386, build id 2001022105. Ran it for 30minutes on the
referenced URL and Mozilla went from a mem. usage of 19000k to 32000k according
to Task Manager. Hitting 'stop' or going to another URL halted the climbing usage.

Sorry about the dupe by the way.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Just tried this with linux build 2001-02-26-08 and I see a rise in memory usage
of about 500k after 40 minutes of the jpeg refreshing continuously. This is not
very much....

Brian, do you still see this in a new build?

Comment 4

[Brian Poole]

I am unable to test on Linux ATM (catching a ride to the airport in 15 minutes),
but testing on Windows 2000 shows the leak still being there. Build ID 2001022705

Results:
Start browser - 19,500K
5 minutes     - 21,708K
15 minutes    - 23,636K
20 minutes    - 24,208K
25 minutes    - 24,848K
30 minutes    - 25,752K
-- hit stop button, load this bug's Bugzilla entry, wait --
35 minutes    - 25,152K

As you can see, memory usage is rising by an avg. of somewhere around
[6-8]00K/5min after initial loading of the test page. After stopping the browser
and changing URLs the memory usage in fact decreases a bit and does not rise at
all, thus leading me to still be suspicious of the MJPG. Would go test on Linux,
but as I said, must catch a ride to the airport.

Comment 5

[Asa Dotzler [:asa]]

updating component and setting default owner

Comment 6

[pnunn]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 7

[Stuart Parmenter]

fixed

Comment 8

[Terri Preston]

Okay, marking verified