Closed Bug 1187518 Opened 7 years ago Closed 6 years ago

[e10s] Child process leaks in recv_function_udp and recv_function_udp6


(Core :: WebRTC, defect, P5)




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


(Reporter: mccr8, Unassigned)


(Blocks 1 open bug)


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

With the patches to let LSan run in a content process, I see a number of leaks of some kind of sctp networking thing. This is in e10s M2 and regular M2, so I assume it is WebRTC related. The regular m2 leak seems to be in the child process created while running dom/media/tests/mochitest/ipc/test_ipc.html. The stacks don't seem very illuminating.

Direct leak of 256 byte(s) in 1 object(s) allocated from:
    #0 __interceptor_malloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/
    #1 recv_function_udp /builds/slave/try-l64-asan-00000000000000000/build/src/netwerk/sctp/src/user_recv_thread.c:677
18:25:59     INFO -  
    #2 start_thread (/lib/x86_64-linux-gnu/

Direct leak of 256 byte(s) in 1 object(s) allocated from:
    #0 __interceptor_malloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/
    #1 recv_function_udp6 /builds/slave/try-l64-asan-00000000000000000/build/src/netwerk/sctp/src/user_recv_thread.c:881
    #2 start_thread (/lib/x86_64-linux-gnu/
(Bug 1089816 has the patch to make LSan in a child process actually run, though you'll have to remove the suppression for this bug to reproduce it.)
Summary: Child process leaks in recv_function_udp and recv_function_udp6 → [e10s] Child process leaks in recv_function_udp and recv_function_udp6
Andrew - this appears to be an upstream library bug (minor).

Michael - my best guess it that this is caused by the couple of "return (NULL)"'s for multicast/etc which leak udprecvmbuf.
backlog: --- → webRTC+
Rank: 55
Flags: needinfo?(tuexen)
Priority: -- → P5
Randell: I guess you are right. This has been fixed upstream a while ago:
I would be interested to see if the problem still exist with up to date usrsctp
Flags: needinfo?(tuexen)
I did a try run by applying the changes from the commit in comment 3 and removing the suppression from build/sanitizers/lsan_suppressions.txt for this bug and it looks like the leaks still show up.
Flags: needinfo?(tuexen)
Hmm. The memory reported to be leaked is allocated in
when recv_function_udp() is entered. It is freed on exit in
I double checked the code in the github repo and do see a way to exit the function
without freeing the memory.
What I don't understand at all, is that
seems to be executed, since these allocation are not to be reported as leaked.
Is it possible to put in printf()s before
to see if the code gets executed?
Flags: needinfo?(tuexen)
Looking at the LSan suppressions report, this is about 146KB of leaks in Mochitest-2.

I'd bisect the test suite down to try to figure out particular tests that leak, but I often have trouble running these media tests locally.
Whiteboard: [MemShrink] → [MemShrink:P2]
This leak appears to be gone now. The suppression was removed in bug 1311584.
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.