1010198 - Creating RTCPeerConnections seems to leak memory

Status: NEW

(Core :: WebRTC: Networking, defect, P4)

Description

[Nick Tindall]

Attachment: A single page example of the problem. Enter 5000(?) and click "Leak connections".

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36

Steps to reproduce:

Repeat a lot (thousands of times, see attached demo):
    1. Create an RTCPeerConnection
    2. Call createOffer, in the callback;
        3. Set the local description
        4. Call close() on the connection




Actual results:

Memory consumption in "heap-unclassified" grows continually. Even when the offending window is closed it remains high.


Expected results:

Any memory used by RTCPeerConnections which have subsequently been closed and dereferenced should be reclaimed(?)

Comment 1

[Eric Rahm [:erahm]]

Attachment: Memory report prior to running test

Comment 2

[Eric Rahm [:erahm]]

Attachment: Memory report after running test

Comment 3

[Eric Rahm [:erahm]]

Attachment: DMD report

Comment 4

[Eric Rahm [:erahm]]

Did a test run on a local build of central on OS X. It looks like we're definitely leaking security related stuff. Looking at the DMD report it seems like we aren't cleaning up the sipcc::PeerConnection (or maybe just missing some members) and it's DataChannel (which seemingly means we're leaking sockets as well).

Memory report diff (note ~74MB unclassified):

150.81 MB (100.0%) -- explicit
├───78.32 MB (51.93%) -- heap-overhead
│   ├──73.86 MB (48.98%) ── bin-unused
│   ├───3.72 MB (02.47%) ── bookkeeping
│   └───0.73 MB (00.49%) ── page-cache
├───73.82 MB (48.95%) ── heap-unclassified
└───-1.32 MB (-0.88%) ++ (15 tiny)


Interesting DMD entries related to |DtlsIdentity::Generate| call in |sipcc::PeerConnectionImpl::Initialize|:

Unreported: 4,009 blocks in stack trace record 1 of 2,590
 32,841,728 bytes (21,776,888 requested / 11,064,840 slop)

Unreported: ~2,530 blocks in stack trace record 2 of 2,590
 ~10,355,290 bytes (~10,355,290 requested / ~0 slop)
 3.23% of the heap (13.49% cumulative);  4.97% of unreported (20.74% cumulative)

Unreported: ~2,014 blocks in stack trace record 3 of 2,590
 ~8,243,302 bytes (~8,243,302 requested / ~0 slop)

Unreported: ~2,006 blocks in stack trace record 4 of 2,590
 ~8,210,558 bytes (~8,210,558 requested / ~0 slop)

Unreported: 990 blocks in stack trace record 5 of 2,590
 8,110,080 bytes (5,377,680 requested / 2,732,400 slop)

Unreported: ~1,669 blocks in stack trace record 6 of 2,590
 ~6,831,217 bytes (~6,831,217 requested / ~0 slop)

Unreported: ~1,633 blocks in stack trace record 7 of 2,590
 ~6,683,869 bytes (~6,683,869 requested / ~0 slop)

Unreported: ~662 blocks in stack trace record 13 of 2,590
 ~2,709,566 bytes (~2,709,566 requested / ~0 slop)

Unreported: ~656 blocks in stack trace record 14 of 2,590
 ~2,685,008 bytes (~2,685,008 requested / ~0 slop)

Unreported: ~504 blocks in stack trace record 16 of 2,590
 ~2,062,872 bytes (~2,062,872 requested / ~0 slop)

Unreported: ~430 blocks in stack trace record 18 of 2,590
 ~1,759,990 bytes (~1,759,990 requested / ~0 slop)


Interesting DMD entries related to |usrsctp_socket| call in |mozilla::DataChannelConnection::Init|:

Unreported: ~1,211 blocks in stack trace record 8 of 2,590
 ~4,956,623 bytes (~4,956,623 requested / ~0 slop)

Unreported: ~1,163 blocks in stack trace record 9 of 2,590
 ~4,760,159 bytes (~4,760,159 requested / ~0 slop)

Unreported: ~604 blocks in stack trace record 15 of 2,590
 ~2,472,172 bytes (~2,472,172 requested / ~0 slop)

Comment 5

[Eric Rahm [:erahm]]

Possible leak: On failure we should be deleting the TransportLayers in the std::queue in vcmCreateTransportFlow[1]. I don't think that's the actual issue though.


[1] http://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/media/VcmSIPCCBinding.cpp#3177

Comment 6

[Eric Rahm [:erahm]]

Possible leak: We should check for |NS_ERROR_NOT_INITIALIZED| when destroying |layers_| in |TransportFlow::~TransportFlow| [1]. On error we should call |ClearLayers| directly.

[1] http://dxr.mozilla.org/mozilla-central/source/media/mtransport/transportflow.cpp#39

Comment 7

[Maire Reavy [:mreavy]]

We should retest, and file bugs for the individual primary leaks if we can (or at least indicate what the leak stacks are - will LSAN show us more detail doing this sort of test?)

Comment 8

[Andrew McCreight [:mccr8]]

LSan will tell you what the allocation stacks are for things that leaked, which could possibly help.

Comment 9

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.