858615 - Memory leaks (high gfx-surface-win32?) when pointing iframe's src to mjpeg stream

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Dmitry Tabakerov]

Attachment: MemoryProfiles.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1106.241 YaBrowser/1.5.1106.241 Safari/537.4

Steps to reproduce:

<iframe src='path_to_mjpeg_stream' />
(I use iframe instead of img because of this bug https://bugzilla.mozilla.org/show_bug.cgi?id=858600 )


Actual results:

Firefox plays mjpeg nice but eats all availible memory
Also when I entered this iframe with Firebug it flikers (seem to be creating and removing html-elements per each mjpeg-frame)


Expected results:

Just playing stream, no memory leaking

Comment 1

[Phoenix]

Is this reproducible in Safe mode/on clean profile (i.e. without NoScript, Firebug and other possibly installed Add-ons)?

Comment 2

[Dmitry Tabakerov]

(In reply to Phoenix from comment #1)
> Is this reproducible in Safe mode/on clean profile (i.e. without NoScript,
> Firebug and other possibly installed Add-ons)?

yes, memory leaks with all addons and extentions disabled

Comment 3

[Phoenix]

Provide about:memory output for clean run to determine which component is leaking and move this bug to appropriate place

Comment 4

[Dmitry Tabakerov]

Attachment: about:memory with extentions and addons disabled

Comment 5

[Phoenix]

Looks like decoded images not discarded, also heap-unclassified higher than should be.
Also, check is problem exists in current nightly build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-23.0a1.en-US.win32.zip and post about:memory output from it (also with disabled Add-ons)

Comment 6

[Dmitry Tabakerov]

Attachment: Nightly about:memory with addons and extentions disabled

Comment 7

[Nicholas Nethercote [inactive]]

Ugh:

553.86 MB (100.0%) -- explicit
├──402.07 MB (72.59%) ── heap-unclassified

Comment 8

[Nicholas Nethercote [inactive]]

Oh, this is also interesting:

│   │  │  ├───9.03 MB (01.63%) -- window(http://172.20.32.80:9082/mjpeg/test_camera)
│   │  │  │   ├──8.82 MB (01.59%) -- js-compartment(http://172.20.32.80:9082/mjpeg/test_camera)
│   │  │  │   │  ├──6.09 MB (01.10%) ++ gc-heap
│   │  │  │   │  │  ├──3.63 MB (00.66%) ++ shapes
│   │  │  │   │  │  │  ├──1.61 MB (00.29%) ── base [65]
│   │  │  │   │  │  │  ├──1.19 MB (00.22%) ── tree/global-parented [64]
│   │  │  │   │  │  │  └──0.83 MB (00.15%) ── dict [65]
│   │  │  │   │  │  ├──2.23 MB (00.40%) ── objects/function [65]
│   │  │  │   │  │  └──0.23 MB (00.04%) ── sundries [65]
│   │  │  │   │  └──2.72 MB (00.49%) ++ (2 tiny)
│   │  │  │   │     ├──1.84 MB (00.33%) ++ shapes-extra
│   │  │  │   │     │  ├──1.24 MB (00.22%) ── compartment-tables [65]
│   │  │  │   │     │  └──0.60 MB (00.11%) ── tree-shape-kids [63]
│   │  │  │   │     └──0.88 MB (00.16%) ── other-sundries [65]
│   │  │  │   └──0.21 MB (00.04%) ++ (3 tiny)
│   │  │  │      ├──0.14 MB (00.02%) ++ layout
│   │  │  │      │  ├──0.11 MB (00.02%) ── style-sets
│   │  │  │      │  ├──0.02 MB (00.00%) ── pres-shell
│   │  │  │      │  ├──0.00 MB (00.00%) ── frames/sundries
│   │  │  │      │  ├──0.00 MB (00.00%) ── style-contexts
│   │  │  │      │  ├──0.00 MB (00.00%) ── rule-nodes
│   │  │  │      │  ├──0.00 MB (00.00%) ── pres-contexts
│   │  │  │      │  └──0.00 MB (00.00%) ── line-boxes
│   │  │  │      ├──0.08 MB (00.01%) ++ dom
│   │  │  │      │  ├──0.07 MB (00.01%) ── other [66]
│   │  │  │      │  ├──0.01 MB (00.00%) ── event-targets [66]
│   │  │  │      │  ├──0.00 MB (00.00%) ── element-nodes
│   │  │  │      │  └──0.00 MB (00.00%) ── text-nodes
│   │  │  │      └──0.00 MB (00.00%) ── style-sheets

The numbers in square brackets indicate duplicates.  So we have 66 duplicate window objects(!) but only one of them has layout data.

Comment 9

[Seth Fowler [:seth] [:s2h]]

Just confirmed this. There have been a lot of bugs fixed related to mJPEGs recently (for example bug 856602 and bug 856486). I've confirmed that none of them fix this problem. On the positive side, none of them created this problem, either, which is something I was afraid of.

Comment 10

[Seth Fowler [:seth] [:s2h]]

Actually, I should be more precise: I was afraid that bug 856486 created this problem, and my testing indicates that it didn't.

Comment 11

[Jonathan]

I would like to add that this bug appears to apply to Linux amd64, didn't test Linux ia32. I view a stream from a remote webcam streamed with mjpg_streamer directly to the browser. No html. Using Firefox 20.0.1 & 19.0.x is also affected. Firefox just eats ram til the kernel kills it. I have 16GBs, however I just start using a cgroup to limit firefox to 800MBs. I may increase it to a full Gig, as with 12 tabs it currently is using 660GBs.

Comment 12

[Alfred Cellier]

This is happening to me - we made an html page using iframes to monitor some d-link ip cameras - using Firefox v22 (and earlier) on a Mac OS 10.6.8 - firefox real and virtual memory size grows and grows - brings the computer to a standstill - the key code we use is:
<tr>
<div class="box">
<iframe src="http://10.0.1.31:8031/mjpeg.cgi" 
width="460" height="345" class="smart_sizing_iframe noresize" frameborder="0" scrolling="no" >
</iframe>
</div>
</tr>
We would really appreciate if someone could fix this!
<S

Comment 13

[monty19]

I think I am seeing the same or similar with Firefox 23 on Fedora 19.

I set up a motion server earlier today and twice it has eaten all RAM on my system until it has become completely unresponsive.

I can provide the conf file if it's of any value, but it's pretty generic aside from changing the resolution to:
width 1280
height 720

At any rate, if it is the same issue it may provide an easy way to reproduce it.

Comment 14

[Wayne Mery (:wsmwk)]

like bug 625012 ?

Comment 16

[Eric Beuque]

Any news for this bug? Still present in Firefox 27 (see bug 984362).

Comment 17

[Oleg]

Any update? Very consistent on OSX 10.9.4 / Firefox 32.0

I am seeing huge memory leak at the rate of ~60Mbytes/second32.0 mjepeg memory leak.mp4

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0

Comment 18

[Oleg]

Attachment: Firefox 32.0 mjepeg memory leak - OSX Activity monitor video

Comment 19

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

Any reason to have this bug as Unconfirmed?

Comment 20

[Nickolay_Ponomarev]

It might worth noting explicitly that in all the about:memory readings presented by Dmitry the 'explicit' measurement is relatively low; while 'gfx-surface-win32' seems to be the thing that grows uncontrollably.

  535.61 MB ── explicit
  916.21 MB ── gfx-surface-win32
1,510.20 MB ── private
1,452.02 MB ── resident

(Though in bug 882990 comment 25 about:memory still has 'resident' much larger than 'explicit', but a small 'gfx-surface-win32'.)

Comment 21

[Tomas Creemers]

Attachment: firefox.exe MJPEG disk usage.png

When performing the test of letting the MJPEG stream consume 3+GB of memory (and having nothing else but that open and no extensions), I noticed that firefox.exe was writing to places.sqlite and places.sqlite-wal at a rate similar to the memory increase. See attachment, unfortunately in Dutch, but the most important figure is the writing at a pace of ~400kByte/s to places.sqlite and ~700kByte/s to places.sqlite-wal .

Could it be trying to store the MJPEG stream as the tab's favicon, the way it does with GIF animations?

I don't know Firefox' architecture or code, but it seems plausible that the MJPEG stream is handled as a regular image file (including caching it, using it as favicon, ...) instead of a (possibly infinite) stream. This seems supported by bug 882990 comment 14:
> MJPEG is handled outside of the content/media code
This is fine (and even desired) for small MJPEG files but definitely problematic for huge MJPEG files or entire MJPEG streams.

Comment 22

[Jonathan]

Is the talk of win32 meaning the exact same problem I have under Linux X11 if a different bug?

Comment 23

[(Away)]

Tomas: I was able to reproduce the issue on 33.1.1 but not on the latest 34 beta. Can you try it? ftp://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/34.0b10-candidates/build1/win32/

Comment 24

[Tomas Creemers]

(In reply to David Major [:dmajor] (UTC+13) from comment #23)
> Tomas: I was able to reproduce the issue on 33.1.1 but not on the latest 34
> beta. Can you try it?
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/34.0b10-candidates/
> build1/win32/

I have tested the streams both directly and via an iframe.

The test that produced the issue with 33.1.1 did not produce the issue on 34.0b10.

I've tested another link with a much higher bit rate (which shows the problem quicker). It also shows the problem on 33.1.1 and not on 34.0b10.

Perhaps a test on a Linux build would be prudent, but this is worksforme on 34.0b10.

Thanks for the info, David :-)

Comment 25

[(Away)]

(In reply to Nicholas Nethercote [:njn] from comment #7)
> Ugh:
> 
> 553.86 MB (100.0%) -- explicit
> ├──402.07 MB (72.59%) ── heap-unclassified

With Tomas' repro (bug 882990 comment 25) and 33.1.1 on my main desktop, I get a ton of heap-unclassified from:
3, ,   |- xul.dll!mozilla::image::Decoder::AllocateFrame
4, ,   |    xul.dll!mozilla::image::RasterImage::EnsureFrame
5, ,   |    xul.dll!mozilla::image::RasterImage::EnsureFrame
6, ,   |    xul.dll!mozilla::image::imgFrame::Init
7, ,   |    mozglue.dll!je_memalign
8, ,   |    mozglue.dll!arena_malloc

On my secondary machine, with same build and settings, I don't get runaway heap-unclassified numbers. My 'explicit' measurement stays very low! But I do still see runaway commit numbers, which xperf attributes to:
2, ,   |- xul.dll!mozilla::image::RasterImage::InitDecoder
3, ,   |    xul.dll!mozilla::image::Decoder::AllocateFrame
4, ,   |    xul.dll!mozilla::image::RasterImage::EnsureFrame
5, ,   |    xul.dll!mozilla::image::RasterImage::EnsureFrame
6, ,   |    xul.dll!mozilla::image::imgFrame::Init
7, ,   |    mozalloc.dll!mozilla::VolatileBuffer::Init
8, ,   |    KernelBase.dll!VirtualAllocEx

That's strange; I wonder why the different allocator. Also, since the leak doesn't repro on 34, I can't tell whether the heap-unclassified issue has been addressed.

Comment 26

[(Away)]

Seth: njn pointed me to bug 1065818. Will your patch there address the missing reporting in comment 25 (both the malloc and the unreported VolatileBuffers)?

Comment 27

[Seth Fowler [:seth] [:s2h]]

(In reply to David Major [:dmajor] (UTC+13) from comment #26)
> Seth: njn pointed me to bug 1065818. Will your patch there address the
> missing reporting in comment 25 (both the malloc and the unreported
> VolatileBuffers)?

Maybe. I'm honestly not sure, because the problem here is that we're leaking either imgFrame objects, or the surfaces that imgFrame objects hold. If we're leaking them, we won't report them, since there's no way to walk through the object graph to get to them. That said, I'm quite curious what effect bug 1060869 has on this leak, and it should also land soon.

I'm going to leave the needinfo on, because I'd like to see if I can still reproduce this after the things in my current patch queue land.

Comment 28

[Jonathan]

(In reply to Tomas Creemers from comment #24)
> (In reply to David Major [:dmajor] (UTC+13) from comment #23)
> > Tomas: I was able to reproduce the issue on 33.1.1 but not on the latest 34
> > beta. Can you try it?
> > ftp://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/34.0b10-candidates/
> > build1/win32/
> 
> I have tested the streams both directly and via an iframe.
> 
> The test that produced the issue with 33.1.1 did not produce the issue on
> 34.0b10.
> 
> I've tested another link with a much higher bit rate (which shows the
> problem quicker). It also shows the problem on 33.1.1 and not on 34.0b10.
> 
> Perhaps a test on a Linux build would be prudent, but this is worksforme on
> 34.0b10.
> 
> Thanks for the info, David :-)

On linux  amd64 with 34.0b10 I cannot reproduce the leak. Been holding steady running just a mjpeg stream for 45+ minutes.

Comment 29

[Seth Fowler [:seth] [:s2h]]

Pretty sure this is fixed. As far as memory reporting improvements, we'll deal with those in bug 1065818 or a followup.

Comment 30

[Petr Vones]

Firefox 34.0.5, no tabs currently opened, no Flash activated, XP SP3. After several hours of usage:

 49.05 MB ── gfx-surface-win32 <-------------- !
  0.00 MB ── gfx-textures
  0.00 MB ── gfx-tiles-waste
        0 ── ghost-windows
 81.29 MB ── heap-allocated
      218 ── heap-chunks
  1.00 MB ── heap-chunksize
 86.09 MB ── heap-committed
218.00 MB ── heap-mapped
    5.90% ── heap-overhead-ratio
        0 ── host-object-urls
  0.01 MB ── imagelib-surface-cache
  3.39 MB ── js-main-runtime-temporary-peak
        0 ── low-commit-space-events
275.36 MB ── private
264.49 MB ── resident
591.70 MB ── vsize
284.19 MB ── vsize-max-contiguous

I can also post saved memory report.