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/asan_malloc_linux.cc:74 #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/libpthread.so.0+0x7e99) 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/asan_malloc_linux.cc:74 #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/libpthread.so.0+0x7e99)
(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+
Priority: -- → P5
Randell: I guess you are right. This has been fixed upstream a while ago: https://github.com/sctplab/usrsctp/commit/990f52f5cee980d3b6aafaefcc2d8280cdb1bfd2 I would be interested to see if the problem still exist with up to date usrsctp sources...
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. https://treeherder.mozilla.org/#/jobs?repo=try&revision=e0ad43114800
Hmm. The memory reported to be leaked is allocated in https://github.com/sctplab/usrsctp/blob/master/usrsctplib/user_recv_thread.c#L685 when recv_function_udp() is entered. It is freed on exit in https://github.com/sctplab/usrsctp/blob/master/usrsctplib/user_recv_thread.c#L851 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 https://github.com/sctplab/usrsctp/blob/master/usrsctplib/user_recv_thread.c#L848 seems to be executed, since these allocation are not to be reported as leaked. Is it possible to put in printf()s before https://github.com/sctplab/usrsctp/blob/master/usrsctplib/user_recv_thread.c#L847 and https://github.com/sctplab/usrsctp/blob/master/usrsctplib/user_recv_thread.c#L851 to see if the code gets executed?
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.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.