1280351 - Memory Leak MJPEG Stream

Status: REOPENED

(Core :: Graphics: ImageLib, defect, P3)

Description

[j.roussel]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0


I use the following tag in my html page in order to include my webcam stream:

<img  class="img-responsive" src="http://0.0.0.0:5010/videofeed">

In the backend I have a python-Server streaming my webcam.

If I refresh the open tab with the address http://0.0.0.0:5010/videofeed firefox starts to increase memory until it crashes.


Actual results:

memory increases until firefox crashes


Expected results:

solving memory leak

Comment 1

[Jean-Yves Avenard [:jya]]

no idea what this component should be, but certainly not video/playback.

Comment 2

[Timothy Nikkel (:tnikkel)]

Does this happen with any mjpeg stream? Or specific about yours?

Comment 3

[j.roussel]

it also happens with other mjpeg streams. For example I tested this one:

https://cams.weblab.deusto.es/webcam/fishtank1/video.mjpeg

Comment 4

[Timothy Nikkel (:tnikkel)]

(In reply to j.roussel from comment #3)
> it also happens with other mjpeg streams. For example I tested this one:
> 
> https://cams.weblab.deusto.es/webcam/fishtank1/video.mjpeg

I tried that link, left it open for over an hour. Memory use stayed about the same.

Can you reproduce the problem again, but this time take two memory reports, one just after you've loaded the mjpeg stream, and one after the memory use has had a chance to grow a lot (but before crashing)? You can get a memory report by navigating to about:memory in a new window and clicking "Measure and save".

Comment 5

[Loic]

Attachment: memory-report.json.gz

I'm able to reproduce the mlk after reloading the stream2-3 times, the memory use grows up slowly. After closing the tab, the memory is still used and continueto increasing.

Comment 6

[j.roussel]

It only happens if you reload the stream minimum one time. I have the same behavior as Loic.

I saved two memory reports. But I can't see an possibility to add files here.
 
And I don't know which lines are the important ones.

Comment 7

[j.roussel]

Attachment: memory report before memory increase

Comment 8

[j.roussel]

Attachment: memory increase after reloading the stream

Comment 9

[j.roussel]

ah I found it and uploaded both files

Comment 10

[Pascal Chevrel:pascalc (PTO until April 26)]

confirmed by Loic in comment #5

Comment 11

[Timothy Nikkel (:tnikkel)]

I still wasn't able to reproduce with reloading the stream.

Thanks for the memory reports. Both reports point to heap-unclassified as the problem. So to figure out what is in that heap unclassified we'll need to get the ability to reproduce into the hands of someone who can run a DMD ( https://developer.mozilla.org/en-US/docs/Mozilla/Performance/DMD ) build.

Comment 12

[Timothy Nikkel (:tnikkel)]

If I keep that link open in a tab, after a while I get a popup asking if I want to download a file. Do other people get that? I'm guessing the content-type or content-disposition of one of the parts of the multipart stream changes to cause this.

Comment 13

[Charles Attard]

Confirming the memory leak (FF 47.0; Win 7 64), when reading stream from Motion on LAN.

Procedure: OPEN in a new tab a local stream (eg. http://192.168.1.2:8081), then CLOSE the corresponding tab: the memory used by FF increases until Win 7 displays a low memory alert (note: swap-file is disabled on the Win 7 PC).

Material required: Raspberry Pi, USB camera
Software: Raspbian OS, Motion 3.2.12

Comment 14

[Timothy Nikkel (:tnikkel)]

Tried reproducing again, this time on Windows, using https://cams.weblab.deusto.es/webcam/fishtank1/video.mjpeg since I don't have a webcam. Tried reloading and closing the tab. Memory use remained stable. Any help in reproducing the increasing memory usage would be greatly appreciated.

Comment 15

[j.roussel]

It seems that increasing memory usage doesn't occur anymore. I tried with the above link and a local camera stream (firefox 50.0.1 and firefox developer edition 51.0a2)

Comment 16

[j.roussel]

But after a while I also get a popup asking if I want to download a file

Comment 17

[Andrei Purice]

Hey roussel,
Can you still reproduce this issue or should we close it?

Comment 18

[Timothy Nikkel (:tnikkel)]

The previous linked mjpeg stream seems to be dead now. Anyone have another one that can be used for testing?

Comment 19

[Andrei Purice]

Marking this as Resolved > Incomplete since the initial mjpeg stream is unavailable.
Feel free to re-open it or file a new bug if anyone can still reproduce it.

Comment 20

[Timothy Nikkel (:tnikkel)]

It shouldn't be hard to find an mjpeg stream to test this, closing is premature imo.

Comment 21

[Andrei Purice]

Tagging myself for further investigation

Comment 22

[Andrei Purice]

Hey Timothy,
Can I get a little help on how to test this? Do you have a mjpeg stream where we can test it?

Comment 23

[Timothy Nikkel (:tnikkel)]

I don't have an mjpeg stream handy to test. A lot of older webcams on the internet used mjpeg. I did a quick search but I was unable to find one. Sorry. One possibility is to run a small local webserver (maybe using flask or python) that serves an mjpeg stream. But just finding one on the internet is probably easier if you have luck with searching.

Comment 24

[nickmarshall42]

I also have encountered this issue. I don't have a public stream I can provide, but I can provide some details about the issue I've noticed:

• The issue only occurs if the stream is in an <img src="..."> tag
  • If I access the stream directly (by entering the URL in the URL bar) it plays back fine with no performance or memory issues
  • If I view the stream on a webpage (even if I use the inspector to add an img tag to about:blank) the entire tab becomes slow and unresponsive
• The issue only occurs for streams above a certain resolution (haven't pinned down where the actual threshold is, may be computer-dependent)
  • For instance, if the source mjpeg is 800x600, I don't typically see any issues
  • If the source is 1920x1080, the slowness is nearly immediate.
  • I haven't tested in a while, but I think something in the middle like 1280x720 starts off ok, then slowly gets more and more bogged down

It used to bog down the whole browser, to the point that I'd have to kill it via task manager, but recently (not sure which update/version) most of the issues are limited to the offending tab (right-clicking inside the tab with the stream either don't respond or takes a long time, but I can interact with other tabs and can click the X on the tab bar to close the tab).

As far as testing, if you can use something like mjpg-streamer or ustreamer to create a 1920x1080 mjpg stream, you should be able to reproduce/test it.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

Redirect needinfos that are pending on inactive users to the triage owner.
:aosmond, since the bug has high severity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 26

[Timothy Nikkel (:tnikkel)]

(In reply to nickmarshall42 from comment #24)

I also have encountered this issue. I don't have a public stream I can provide, but I can provide some details about the issue I've noticed:

• The issue only occurs if the stream is in an <img src="..."> tag
  • If I access the stream directly (by entering the URL in the URL bar) it plays back fine with no performance or memory issues
  • If I view the stream on a webpage (even if I use the inspector to add an img tag to about:blank) the entire tab becomes slow and unresponsive
• The issue only occurs for streams above a certain resolution (haven't pinned down where the actual threshold is, may be computer-dependent)
  • For instance, if the source mjpeg is 800x600, I don't typically see any issues
  • If the source is 1920x1080, the slowness is nearly immediate.
  • I haven't tested in a while, but I think something in the middle like 1280x720 starts off ok, then slowly gets more and more bogged down

It used to bog down the whole browser, to the point that I'd have to kill it via task manager, but recently (not sure which update/version) most of the issues are limited to the offending tab (right-clicking inside the tab with the stream either don't respond or takes a long time, but I can interact with other tabs and can click the X on the tab bar to close the tab).

As far as testing, if you can use something like mjpg-streamer or ustreamer to create a 1920x1080 mjpg stream, you should be able to reproduce/test it.

This sounds more like bug 1745274. This bug is about a memory leak.

Comment 27

[Timothy Nikkel (:tnikkel)]

Gave another try at reproducing this, with several relods, in a foreground tab and a background tab. No memory increase.

Comment 28

[Arthur]

This bug has went to school now)
Looks like I'm having it.
How can I help to debug it?

Comment 29

[Arthur]

As the mater of fact, maybe I've to the wrong place, since for me MJPEG stream not a memory leak, but 100% CPU core load from the corresponding Firefox.exe process and tab lockup.

Comment 30

[Timothy Nikkel (:tnikkel)]

Just curious, what is the cpu you see this on? How big is the mjpeg stream and how many fps is it?

Comment 31

[Arthur]

Oh, my CPU is Intel Core i7-8650U 3,2GHz. It's a mobile CPU.
The stream is from Logitech C270 connected to Orange PI streamed by mjpg-streamer.
VLC measured 1280x960 2MB/s