Closed Bug 914015 Opened 11 years ago Closed 10 years ago

mozRTCPeerConnection leak

Categories

(Core :: WebRTC: Signaling, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

Details

(Keywords: memory-leak, testcase, Whiteboard: [webrtc])

Attachments

(2 files)

Attached file testcase
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.
Attached file leak info
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]
crypto.expando makes us preserve crypto's wrapper.
Component: WebRTC: Networking → WebRTC: Signaling
[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)
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.

Attachment

General

Creator:
Created:
Updated:
Size: