[e10s] Child process leaks in recv_function_udp and recv_function_udp6

RESOLVED WORKSFORME

Status

()

Core
WebRTC
P5
normal
Rank:
55
RESOLVED WORKSFORME
3 years ago
a year ago

People

(Reporter: mccr8, Unassigned)

Tracking

(Blocks: 1 bug, {memory-leak})

Trunk
memory-leak
Points:
---

Firefox Tracking Flags

(e10s+, firefox42 affected)

Details

(Whiteboard: [MemShrink:P2])

(Reporter)

Description

3 years ago
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)
(Reporter)

Comment 1

3 years ago
(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.)
(Reporter)

Updated

3 years ago
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

Comment 3

3 years ago
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)
tracking-e10s: --- → +
(Reporter)

Comment 4

3 years ago
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

Updated

3 years ago
Flags: needinfo?(tuexen)

Comment 5

3 years ago
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)
(Reporter)

Comment 6

3 years ago
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.