Closed Bug 858615 Opened 7 years ago Closed 5 years ago

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

Categories

(Core :: ImageLib, defect)

20 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: i, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(5 files)

Attached file 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
Is this reproducible in Safe mode/on clean profile (i.e. without NoScript, Firebug and other possibly installed Add-ons)?
Flags: needinfo?(i)
(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
Flags: needinfo?(i)
Provide about:memory output for clean run to determine which component is leaking and move this bug to appropriate place
Flags: needinfo?(i)
Flags: needinfo?(i)
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)
Blocks: DarkMatter
Component: Untriaged → ImageLib
Product: Firefox → Core
Whiteboard: [MemShrink]
Ugh:

553.86 MB (100.0%) -- explicit
├──402.07 MB (72.59%) ── heap-unclassified
Whiteboard: [MemShrink] → [MemShrink:P2]
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.
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.
Actually, I should be more precise: I was afraid that bug 856486 created this problem, and my testing indicates that it didn't.
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.
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
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.
Duplicate of this bug: 984362
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
Blocks: 882990
Any reason to have this bug as Unconfirmed?
Status: UNCONFIRMED → NEW
Ever confirmed: true
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'.)
Summary: Memory leaks when pointing iframe's src to mjpeg stream → Memory leaks (high gfx-surface-win32?) when pointing iframe's src to mjpeg stream
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.
Is the talk of win32 meaning the exact same problem I have under Linux X11 if a different bug?
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/
Flags: needinfo?(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 :-)
Flags: needinfo?(tomas.creemers)
(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.
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)?
Flags: needinfo?(seth)
(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.
(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.
Pretty sure this is fixed. As far as memory reporting improvements, we'll deal with those in bug 1065818 or a followup.
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(seth)
Resolution: --- → WORKSFORME
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.
You need to log in before you can comment on or make changes to this bug.