Open Bug 1569311 Opened 6 years ago Updated 6 months ago

StunAddrsRequestParent and StunAddrsRequestChild are not freed until shutdown

Categories

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

70 Branch
defect

Tracking

()

Tracking Status
firefox70 --- affected

People

(Reporter: dminor, Unassigned)

Details

A StunAddrsRequestChild and StunAddrsRequestParent are allocated every time we create a PeerConnectionMedia instance, in InitLocalAddrs(). The PeerConnectionMedia instance is freed along with the PeerConnection after it is closed during browsing, but the StunAddrsRequestChild and StunAddrsRequestParent stick around until shutdown.

For instance, on aliexpress.com (which apparently uses PeerConnections for fingerprinting) navigating through a few pages with some extra logging ends up looking like this:

PCM::InitLocalAddrs
StunAddrsRequestChild::ctor
StunAddrsRequestParent::ctor
PCM::InitLocalAddrs
StunAddrsRequestChild::ctor
StunAddrsRequestParent::ctor
PeerConnectionMedia::SelfDestruct_m()
PeerConnectionMedia::SelfDestruct_m()
PCM::InitLocalAddrs
StunAddrsRequestChild::ctor
StunAddrsRequestParent::ctor
PCM::InitLocalAddrs
StunAddrsRequestChild::ctor
StunAddrsRequestParent::ctor
PeerConnectionMedia::SelfDestruct_m()
PeerConnectionMedia::SelfDestruct_m()
PCM::InitLocalAddrs
StunAddrsRequestChild::ctor
StunAddrsRequestParent::ctor
PCM::InitLocalAddrs
StunAddrsRequestChild::ctor
StunAddrsRequestParent::ctor
PeerConnectionMedia::SelfDestruct_m()
PeerConnectionMedia::SelfDestruct_m()
StunAddrsRequestChild::dtor
StunAddrsRequestChild::dtor
StunAddrsRequestChild::dtor
StunAddrsRequestChild::dtor
StunAddrsRequestChild::dtor
StunAddrsRequestChild::dtor
StunAddrsRequestParent::dtor
StunAddrsRequestParent::dtor
StunAddrsRequestParent::dtor
StunAddrsRequestParent::dtor
StunAddrsRequestParent::dtor
StunAddrsRequestParent::dtor

This isn't a memory leak as they are eventually freed, but I would have expected the lifetime of the StunAddrsRequestChild and StunAddrsRequestParent to have been similar to that of PeerConnectionMedia.

I'm not sure if this is a regression or not. If this is the expected behaviour, we should probably consider making the StunAddrsRequest child/parent pair singletons so we don't end up using more memory than necessary.

This is because we never call Send__delete__ on mStunAddrRequest in PeerConnectionMedia. According to [1] we should be doing this, and re-testing on aliexpress with this call added and logging like the above shows the destructors firing as I navigate pages rather than at shutdown. Making this change will also require changes to the lifetime of the mdns_service singleton which is owned by StunAddrRequestParent.

[1] https://developer.mozilla.org/en-US/docs/Mozilla/IPDL/Best_Practices

Assignee: nobody → dminor
Assignee: dminor → nobody
Severity: normal → S3
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.