Closed Bug 1275200 Opened 8 years ago Closed 8 years ago

WebRTC: memory leak using DataChannel

Categories

(Core :: WebRTC, defect)

46 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: smayoral, Unassigned)

Details

(Whiteboard: [MemShrink])

Attachments

(5 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

Steps to reproduce:

My windows application opens a DataChannel to Firefox and I transmit PNG images which will be displayed in a canvas object.


Actual results:

Firefox stops receiving data and Windows Task Manages shows a huge memory usage for Firefox, more than 700 MB. Firefox even crashes sometimes.


Expected results:

Firefox should free allocated memory and keep receiving data over the DataChannel.
Version 45.0.2 works correctly.
Component: Untriaged → WebRTC
Could you type about:memory in the location bar, then save and attach a memory log when the issue appears.

In addition, could you provide a simple testcase to reproduce the issue.
Flags: needinfo?(smayoral)
Attached file memory-report.json.gz
I just open a DataChannel and send many PNG images to it. I have just tested that the problem appears even so:

        var onDataChannelMessage = function (event) {
        }

I do nothing with the received data. I think you should be able to reproduce it. Maybe it depends how fast Firefox is receiving data.
Whiteboard: [MemShrink]
106MB of heap-unclassified for 11MB of canvas pixel data, I call that a smoking gun.

Sergio, would you be able to give us a way to reproduce the problem so we can investigate?

Jesup, any idea off hand in this range (works in 45, does not work in 46).
Flags: needinfo?(rjesup)
my windows application is sharing the desktop or just an application, applies PNG/JPEG compression and send the data over DTLS/SCTP to Firefox. 
It is difficult for me to provide you a way to reproduce the problem. 
But as I said, in the onDataChannelMessage associated with the DataChannel I just returned without doing anything with the data and the problem still persists.
The point is that I eventually send a high bitrate to Firefox, nearly 1MB/sec.
How large are the messages?  Are they ArrayBuffers or Blobs?  Is the leak on the receiving side, or the sending side?  If need be, open two browsers on the same machine and make the call between them.  (./firefox -profilemanager -no-remote   will let you run multiple browsers and profiles easily)  Is this all over a single DataChannel? (I assume so).

Can you provoke a leak, then open a tab with about:memory and select Minimize Memory Usage, and see if the leak disappears.  Then close one of the tabs, Minimize again, and check.  Then the other tab, and repeat.  (This will also will help determine which side is the cause)

Thanks
Flags: needinfo?(rjesup)
- different sizes, from 20 KB to some bytes
- ArrayBuffers
- Firefox only at the receiving side. Sending side is a windows application (.exe)
Can you perform the diagnostic steps in comment 6? That should give us an idea of where the problem lies.
Whiteboard: [MemShrink] → [MemShrink][needinfo reporter 5/31/16]
i already attached a memory dump and as i said, there is only Firefox at the receiving side. I will try to do the diagnostic next week.
Sergio: Per comment 6, we would like a dump of about:memory after selecting Minimize Memory Usage.  (See comment 6).  I think it's just data waiting for GC, but if it isn't this will show that.  (Since Firefox is receiving data from a windows exe, you can ignore the "other tab" questions).  Thanks
Whiteboard: [MemShrink][needinfo reporter 5/31/16] → [MemShrink][needinfo reporter 6/1/16]
Hi, selecting Minimize Memory Usage did not help. I am not able to get a memory dump when Firefox is using over 800 MB, only till 600 MB. I hope you can find the problem. Thanks.
Attached file memory-report.json.gz
Attached image memory.png
Flags: needinfo?(smayoral)
Whiteboard: [MemShrink][needinfo reporter 6/1/16] → [MemShrink]
I think we can close this issue, new version 47 works ok.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: