[Bug network/16001] New: calls to getaddrinfo() leak memory.

[Bug network/16001] New: calls to getaddrinfo() leak memory.

[dbavatar at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16001

            Bug ID: 16001
           Summary: calls to getaddrinfo() leak memory.
           Product: glibc
           Version: 2.18
            Status: NEW
          Severity: normal
          Priority: P2
         Component: network
          Assignee: unassigned at sourceware dot org
          Reporter: dbavatar at gmail dot com

Created attachment 7223
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7223&action=edit
Leak test case.

Calls to getaddrinfo() followed by freeaddrinfo() leak memory. Test case
attached. Sending fix patch to libc-alpha.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/16001] calls to getaddrinfo() leak memory.

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16001

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
This is not how the addrinfo storage returned by getaddrinfo is supposed to be
deallocated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/16001] calls to getaddrinfo() leak memory.

[dbavatar at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16001

--- Comment #2 from Debabrata Banerjee <dbavatar at gmail dot com> ---
(In reply to Andreas Schwab from comment #1)
> This is not how the addrinfo storage returned by getaddrinfo is supposed to
> be deallocated.

What? This most certainly is a valid bug. My patch was superseded by better
ideas about how to fix it. Whether or not it was resolved in tree yet is a good
question.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/16001] calls to getaddrinfo() leak memory.

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16001

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/16001] calls to getaddrinfo() leak memory.

[aoliva at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16001

Alexandre Oliva <aoliva at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at sourceware dot org

--- Comment #3 from Alexandre Oliva <aoliva at sourceware dot org> ---
I see the testcase duplicates freeaddrinfo behavior, but I don't see how it
shows there is (or was) any memory leak.  I couldn't locate the patch
submission nor the better ideas about how to fix it to tell whether this should
be reopened or left closed.  Pointers anyone?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/16001] calls to getaddrinfo() leak memory.

[dbavatar at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16001

--- Comment #4 from Debabrata Banerjee <dbavatar at gmail dot com> ---
(In reply to Alexandre Oliva from comment #3)
> I see the testcase duplicates freeaddrinfo behavior, but I don't see how it
> shows there is (or was) any memory leak.  I couldn't locate the patch
> submission nor the better ideas about how to fix it to tell whether this
> should be reopened or left closed.  Pointers anyone?

Hi, If you create a large number of local interfaces, then you should be able
to reproduce it with the test case attached. i.e. Create 16,000 eth0:xxxxx
aliases and assign a new IPv4 address to each one.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/16001] calls to getaddrinfo() leak memory.

[aoliva at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16001

--- Comment #6 from Alexandre Oliva <aoliva at sourceware dot org> ---
It looks like there is a proposed patch for this bug at
https://www.sourceware.org/ml/libc-alpha/2013-10/msg00190.html with a bit of
additional info on how to reproduce it.  It would have been nice to have had
them cross-referenced.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/16001] calls to getaddrinfo() leak memory.

[aoliva at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16001

--- Comment #7 from Alexandre Oliva <aoliva at sourceware dot org> ---
The current refcounting code is significantly different now than it was when
you reported the patch.  I see usecnt is initialized to 2 (1 use for the cache,
1 use to be freed by the caller), and it's incremented when the cached list is
reused, and decremented when the cache is replaced or when the list is freed. 
I don't see how this could possibly leak in6ai lists.  Is this what used to
leak before?  If so, can you confirm that the problem is fixed?

One problem I do see is that getaddrinfo, the only caller of check_pf, sorts a
potentially shared in6ai list without any guards to prevent multiple threads
from trying to do that concurrently and messing the array up.

-- 
You are receiving this mail because:
You are on the CC list for the bug.