Closed
Bug 914015
Opened 11 years ago
Closed 10 years ago
mozRTCPeerConnection leak
Categories
(Core :: WebRTC: Signaling, defect)
Core
WebRTC: Signaling
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jruderman, Unassigned)
Details
(Keywords: memory-leak, testcase, Whiteboard: [webrtc])
Attachments
(2 files)
1. Run a debug build with XPCOM_MEM_LEAK_LOG=2 2. Load the testcase 3. Quit trace-refcnt reports leaked nsGlobalWindow and nsDocument objects.
Reporter | ||
Comment 1•11 years ago
|
||
Comment 2•11 years ago
|
||
While I'm not sure why the crypto.expando = null line is needed (no leak without it), I suspect the window.b = (new RTCPeerConnection()).localstreams is causing some sort of uncollectable cycle between window and the localstreams array (and not surprisingly putting the peerconnection in a var makes no difference).
OS: Mac OS X → All
Hardware: x86_64 → All
Whiteboard: [webrtc]
Comment 3•11 years ago
|
||
crypto.expando makes us preserve crypto's wrapper.
Updated•11 years ago
|
Component: WebRTC: Networking → WebRTC: Signaling
Comment 4•11 years ago
|
||
[15:28] smaug jesup: in nsGlobalWindow::GetCrypto [15:28] smaug there is FORWARD_TO_OUTER [15:29] smaug change that to FORWARD_TO_INNER Tried that, but no go.
Appears to WFM on tip. Can you confirm?
Flags: needinfo?(rjesup)
Comment 6•10 years ago
|
||
WFM too on inbound
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(rjesup)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•