Leak of fds allocated in nsSocketTransport::BuildSocket()

RESOLVED DUPLICATE of bug 1028456

Status

()

Core
Networking
RESOLVED DUPLICATE of bug 1028456
4 years ago
2 years ago

People

(Reporter: mccr8, Assigned: mccr8)

Tracking

(Blocks: 1 bug, {mlk})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
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.)
(Assignee)

Comment 1

4 years ago
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
(Assignee)

Comment 2

4 years ago
Created attachment 8438588 [details]
socket leak from test_bug_945152.html

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

Updated

4 years ago
Whiteboard: [MemShrink]
Whiteboard: [MemShrink] → [MemShrink:P2]
(Assignee)

Comment 3

4 years ago
Nick, could you run this under valgrind so we can figure out if we're really leaking a file descriptor?
Flags: needinfo?(n.nethercote)
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>
Flags: needinfo?(n.nethercote)
(Assignee)

Updated

3 years ago
Depends on: 573192
comment 4
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
(Assignee)

Comment 6

2 years ago
(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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Updated

2 years ago
Assignee: nobody → continuation
(Assignee)

Comment 7

2 years ago
I'll just consolidate these NSPR fd issues into a single bug, and remove some of the redundant suppressions.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1028456
You need to log in before you can comment on or make changes to this bug.