1187518 - [e10s] Child process leaks in recv_function_udp and recv_function_udp6

Status: RESOLVED WORKSFORME

(Core :: WebRTC, defect, P5)

Description

[Andrew McCreight [:mccr8]]

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)

Comment 1

[Andrew McCreight [:mccr8]]

(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.)

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 3

[Michael Tüxen]

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...

Comment 4

[Andrew McCreight [:mccr8]]

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

Comment 5

[Michael Tüxen]

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?

Comment 6

[Andrew McCreight [:mccr8]]

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.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

This leak appears to be gone now. The suppression was removed in bug 1311584.