public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug network/16001] New: calls to getaddrinfo() leak memory.
@ 2013-10-04 20:14 dbavatar at gmail dot com
2014-06-05 14:24 ` [Bug network/16001] " schwab@linux-m68k.org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: dbavatar at gmail dot com @ 2013-10-04 20:14 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug network/16001] calls to getaddrinfo() leak memory.
2013-10-04 20:14 [Bug network/16001] New: calls to getaddrinfo() leak memory dbavatar at gmail dot com
@ 2014-06-05 14:24 ` schwab@linux-m68k.org
2014-06-05 16:04 ` dbavatar at gmail dot com
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: schwab@linux-m68k.org @ 2014-06-05 14:24 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug network/16001] calls to getaddrinfo() leak memory.
2013-10-04 20:14 [Bug network/16001] New: calls to getaddrinfo() leak memory dbavatar at gmail dot com
2014-06-05 14:24 ` [Bug network/16001] " schwab@linux-m68k.org
@ 2014-06-05 16:04 ` dbavatar at gmail dot com
2014-06-13 12:43 ` fweimer at redhat dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: dbavatar at gmail dot com @ 2014-06-05 16:04 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug network/16001] calls to getaddrinfo() leak memory.
2013-10-04 20:14 [Bug network/16001] New: calls to getaddrinfo() leak memory dbavatar at gmail dot com
2014-06-05 14:24 ` [Bug network/16001] " schwab@linux-m68k.org
2014-06-05 16:04 ` dbavatar at gmail dot com
@ 2014-06-13 12:43 ` fweimer at redhat dot com
2014-09-29 8:17 ` aoliva at sourceware dot org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: fweimer at redhat dot com @ 2014-06-13 12:43 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug network/16001] calls to getaddrinfo() leak memory.
2013-10-04 20:14 [Bug network/16001] New: calls to getaddrinfo() leak memory dbavatar at gmail dot com
` (2 preceding siblings ...)
2014-06-13 12:43 ` fweimer at redhat dot com
@ 2014-09-29 8:17 ` aoliva at sourceware dot org
2014-10-13 3:12 ` dbavatar at gmail dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: aoliva at sourceware dot org @ 2014-09-29 8:17 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug network/16001] calls to getaddrinfo() leak memory.
2013-10-04 20:14 [Bug network/16001] New: calls to getaddrinfo() leak memory dbavatar at gmail dot com
` (3 preceding siblings ...)
2014-09-29 8:17 ` aoliva at sourceware dot org
@ 2014-10-13 3:12 ` dbavatar at gmail dot com
2014-10-31 7:27 ` aoliva at sourceware dot org
2014-10-31 8:12 ` aoliva at sourceware dot org
6 siblings, 0 replies; 8+ messages in thread
From: dbavatar at gmail dot com @ 2014-10-13 3:12 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug network/16001] calls to getaddrinfo() leak memory.
2013-10-04 20:14 [Bug network/16001] New: calls to getaddrinfo() leak memory dbavatar at gmail dot com
` (4 preceding siblings ...)
2014-10-13 3:12 ` dbavatar at gmail dot com
@ 2014-10-31 7:27 ` aoliva at sourceware dot org
2014-10-31 8:12 ` aoliva at sourceware dot org
6 siblings, 0 replies; 8+ messages in thread
From: aoliva at sourceware dot org @ 2014-10-31 7:27 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug network/16001] calls to getaddrinfo() leak memory.
2013-10-04 20:14 [Bug network/16001] New: calls to getaddrinfo() leak memory dbavatar at gmail dot com
` (5 preceding siblings ...)
2014-10-31 7:27 ` aoliva at sourceware dot org
@ 2014-10-31 8:12 ` aoliva at sourceware dot org
6 siblings, 0 replies; 8+ messages in thread
From: aoliva at sourceware dot org @ 2014-10-31 8:12 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-10-31 8:12 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-04 20:14 [Bug network/16001] New: calls to getaddrinfo() leak memory dbavatar at gmail dot com
2014-06-05 14:24 ` [Bug network/16001] " schwab@linux-m68k.org
2014-06-05 16:04 ` dbavatar at gmail dot com
2014-06-13 12:43 ` fweimer at redhat dot com
2014-09-29 8:17 ` aoliva at sourceware dot org
2014-10-13 3:12 ` dbavatar at gmail dot com
2014-10-31 7:27 ` aoliva at sourceware dot org
2014-10-31 8:12 ` aoliva at sourceware dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).