1021302 - Leak of fds allocated in nsSocketTransport::BuildSocket()

Status: RESOLVED DUPLICATE of bug 1028456

(Core :: Networking, defect)

Description

[Andrew McCreight [:mccr8]]

This is not super helpful, but LSAN reports what looks like some leaked fds in a Mochitest-1 run, allocated with these stacks:

Direct leak of 96 byte(s) in 2 object(s) allocated from:
    #0 0x471d41 in malloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
    #1 0x7fc0b5d880ab in _PR_Getfd /build/nsprpub/pr/src/io/prfdcach.c:109
    #2 0x7fc0b5dc6637 in pt_SetMethods /build/nsprpub/pr/src/pthreads/ptio.c:3303
    #3 0x7fc0b5dc6e5a in PR_Socket /build/nsprpub/pr/src/pthreads/ptio.c:3505
    #4 0x7fc0a14cd872 in nsSocketTransport::BuildSocket(PRFileDesc*&, bool&, bool&) /build/netwerk/base/src/nsSocketTransport2.cpp:1058

Indirect leak of 80 byte(s) in 2 object(s) allocated from:
    #0 0x471d41 in malloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
    #1 0x7fc0b5d880c3 in _PR_Getfd /build/nsprpub/pr/src/io/prfdcach.c:112
    #2 0x7fc0b5dc6637 in pt_SetMethods /build/nsprpub/pr/src/pthreads/ptio.c:3303
    #3 0x7fc0b5dc6e5a in PR_Socket /build/nsprpub/pr/src/pthreads/ptio.c:3505
    #4 0x7fc0a14cd872 in nsSocketTransport::BuildSocket(PRFileDesc*&, bool&, bool&) /build/netwerk/base/src/nsSocketTransport2.cpp:1058

(This is from an opt build, so it could be the result of some cleanup we don't bother doing in non-debug builds.)

Comment 1

[Andrew McCreight [:mccr8]]

There's a similar-ish looking one in Moth:

Direct leak of 96 byte(s) in 2 object(s) allocated from:
    #0 0x471d41 in malloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:74
    #1 0x7f88a027709b in _PR_Getfd /build/nsprpub/pr/src/io/prfdcach.c:109
    #2 0x7f88a02b56c7 in pt_SetMethods /build/nsprpub/pr/src/pthreads/ptio.c:3303
    #3 0x7f88a02c075b in pt_Accept /build/nsprpub/pr/src/pthreads/ptio.c:1707
    #4 0x7f888658d4fc in nsServerSocket::OnSocketReady(PRFileDesc*, short) /build/netwerk/base/src/nsServerSocket.cpp:186

Comment 2

[Andrew McCreight [:mccr8]]

Attachment: socket leak from test_bug_945152.html

This particular test in mochitest-chrome seems to leak the memory allocated by a socket.

Comment 3

[Andrew McCreight [:mccr8]]

Nick, could you run this under valgrind so we can figure out if we're really leaking a file descriptor?

Comment 4

[Nicholas Nethercote [inactive]]

No apparent fd leaks! Valgrind says that after running that test and exiting
the mochitest harness, the only fds open are stdin, stdout and stderr, as you'd
expect.

For posterity, here's how I did it.  With a --enable-valgrind build, I did this:
- I modified the "valgrind" args in build/automationutils.py to include --track-fds=yes.
- I ran this command:
> mach mochitest-chrome --debugger valgrind --keep-open ./dom/apps/tests/test_bug_945152.html

  The relevant output was the following.

> ==5653== FILE DESCRIPTORS: 3 open at exit.
> ==5653== Open file descriptor 2: /dev/null
> ==5653==    at 0x5949DF7: dup2 (syscall-template.S:81)
> ==5653==    by 0x979A8E6: glxtest (glxtest.cpp:118)
> ==5653==    by 0x979AD13: fire_glxtest_process() (glxtest.cpp:277)
> ==5653==    by 0x97920BA: XREMain::XRE_mainInit(bool*) (nsAppRunner.cpp:2869)
> ==5653==    by 0x9796967: XREMain::XRE_main(int, char**, nsXREAppData const*) (nsAppRunner.cpp:4062)
> ==5653==    by 0x9796C96: XRE_main (nsAppRunner.cpp:4296)
> ==5653==    by 0x40395E: do_main(int, char**, nsIFile*) (nsBrowserApp.cpp:282)
> ==5653==    by 0x403AAF: main (nsBrowserApp.cpp:643)
> ==5653==
> ==5653== Open file descriptor 1: /dev/null
> ==5653==    at 0x5949DF7: dup2 (syscall-template.S:81)
> ==5653==    by 0x979A8E6: glxtest (glxtest.cpp:118)
> ==5653==    by 0x979AD13: fire_glxtest_process() (glxtest.cpp:277)
> ==5653==    by 0x97920BA: XREMain::XRE_mainInit(bool*) (nsAppRunner.cpp:2869)
> ==5653==    by 0x9796967: XREMain::XRE_main(int, char**, nsXREAppData const*) (nsAppRunner.cpp:4062)
> ==5653==    by 0x9796C96: XRE_main (nsAppRunner.cpp:4296)
> ==5653==    by 0x40395E: do_main(int, char**, nsIFile*) (nsBrowserApp.cpp:282)
> ==5653==    by 0x403AAF: main (nsBrowserApp.cpp:643)
> ==5653==
> ==5653== Open file descriptor 0: /dev/pts/17
> ==5653==    <inherited from parent>

Comment 5

[Patrick McManus [:mcmanus]]

comment 4

Comment 6

[Andrew McCreight [:mccr8]]

(In reply to Patrick McManus [:mcmanus] from comment #5)
> comment 4

Comment 4 was about whether we were leaking actual OS file descriptors. The original bug was about leaking some NSPR file-descriptor-related memory. That said, looking at some LSan logs, I don't think we're hitting this suppression any more. I'll try removing it and see if that is green. I think erahm fixed some NSPR-related fd issues.

Comment 7

[Andrew McCreight [:mccr8]]

I'll just consolidate these NSPR fd issues into a single bug, and remove some of the redundant suppressions.