mozRTCPeerConnection leak

RESOLVED WORKSFORME

Status

()

Core
WebRTC: Signaling
RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 1 bug, {memory-leak, testcase})

Trunk
memory-leak, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [webrtc])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 801355 [details]
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.
(Reporter)

Comment 1

5 years ago
Created attachment 801356 [details]
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]

Comment 3

5 years ago
crypto.expando makes us preserve crypto's wrapper.

Updated

5 years ago
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
Last Resolved: 4 years ago
Flags: needinfo?(rjesup)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.