Closed
Bug 914015
Opened 12 years ago
Closed 12 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•12 years ago
|
||
|
||
Comment 2•12 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•12 years ago
|
||
crypto.expando makes us preserve crypto's wrapper.
|
||
Updated•12 years ago
|
Component: WebRTC: Networking → WebRTC: Signaling
|
|
||
Comment 4•12 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•12 years ago
|
||
WFM too on inbound
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: needinfo?(rjesup)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•