Closed Bug 1187424 Opened 9 years ago Closed 9 years ago

[e10s] desktop capture's DesktopApplication does not free any of its string members


(Core :: WebRTC, defect, P4)




Tracking Status
e10s + ---
firefox42 --- affected


(Reporter: mccr8, Unassigned)


(Blocks 1 open bug)


(Keywords: memory-leak, Whiteboard: [MemShrink:P3])

In an LSan run of e10s m2, I see a number of leaks like this:

Direct leak of 31 byte(s) in 1 object(s).
    #0 0x475951 in operator new[](unsigned long) /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/
    #1 0x7fe0d5186fbb in SetStringMember src/media/webrtc/trunk/webrtc/modules/desktop_capture/
    #2 0x7fe0d5186fbb in webrtc::DesktopApplication::setProcessAppName(char const*) src/media/webrtc/trunk/webrtc/modules/desktop_capture/
    #3 0x7fe0d519d6fd in webrtc::DesktopDeviceInfoX11::InitializeApplicationList() src/media/webrtc/trunk/webrtc/modules/desktop_capture/x11/
    #4 0x7fe0d5188492 in webrtc::DesktopDeviceInfoImpl::Init() src/media/webrtc/trunk/webrtc/modules/desktop_capture/
    #5 0x7fe0d51a8b22 in Create src/media/webrtc/trunk/webrtc/modules/desktop_capture/x11/

There are variants with setProcessPathName and setUniqueIdName instead of setProcessAppName. I think the problem is that DesktopApplication fails to free processPathNameUTF8_, applicationNameUTF8_ and processUniqueIdUTF8_ in its dtor, though this code does carefully use SetStringMember() to ensure that overwriting a value doesn't leak the old string.

This is less than a few hundred bytes of leaks in the e10s m2 run.
backlog: --- → webRTC+
Rank: 45
Priority: -- → P4
Whiteboard: [MemShrink] → [MemShrink:P3]
Assignee: nobody → continuation
Assignee: continuation → nobody
I'm not seeing this any more, though the problem still exists as far as I can see. Maybe the strings are cleaned up some other way. I'll remove the suppression in bug 1201096.
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.