Motion JPEG network cameras cause memory leakage

VERIFIED FIXED in mozilla1.0



18 years ago
17 years ago


(Reporter: Brian Poole, Assigned: Stuart Parmenter)



Firefox Tracking Flags

(Not tracked)





18 years ago
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 (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.
*** Bug 69858 has been marked as a duplicate of this bug. ***

Comment 2

18 years ago
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.
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

18 years ago
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

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

18 years ago
updating component and setting default owner
Assignee: asa → pnunn
Component: Browser-General → ImageLib
Ever confirmed: true
QA Contact: doronr → tpreston


18 years ago
Target Milestone: --- → mozilla1.0


18 years ago

Comment 6

18 years ago
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov

Comment 7

17 years ago
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 8

17 years ago
Okay, marking verified
You need to log in before you can comment on or make changes to this bug.