This is the mail archive of the
mailing list for the glibc project.
On Mon, 2017-06-19 at 13:27 +0100, Phil Blundell wrote:
> If gai_cancel() removes the entry from the request queue then, as the
> code stands today, nothing will cause __gai_notify() to be called for
> it and hence the async_waitlist is never freed.
>From inspection of the code I think there is another leak too:
__gai_remove_request() unlinks "runp" from the request list, but as far
as I can tell there is nothing that will ever put it back in the
freelist so that element is essentially lost.
This leak is not immediately obvious from the mtrace or valgrind
output, because all the "struct requestlist" objects live in a single
block that was calloc()ed in get_elem() and the block itself is not
lost, but if you run a test that simply calls getaddrinfo_a() and
gai_cancel() in a loop then you can see that the process size keeps
growing without any obvious bound. (On my machine it reached 4G of rss
within a couple of seconds at which point I killed it.)