Closed Bug 1187518 Opened 7 years ago Closed 6 years ago

[e10s] Child process leaks in recv_function_udp and recv_function_udp6

Categories

(Core :: WebRTC, defect, P5)

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
e10s + ---
firefox42 --- affected

People

(Reporter: mccr8, Unassigned)

References

(Blocks 1 open bug)

Details

(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/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+
Rank: 55
Flags: needinfo?(tuexen)
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...
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.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e0ad43114800
Flags: needinfo?(tuexen)
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?
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.