This is the mail archive of the
mailing list for the glibc project.
On Mon, 2017-06-19 at 13:51 +0200, Florian Weimer wrote:
> How does the memory leak happen? Would another notification
> deallocate the struct async_waitlist object?
The async_waitlist is allocated in getaddrinfo_a and, under normal
circumstances, freed by this dubious-looking code in __gai_notify():
/* This is tricky. See getaddrinfo_a.c for the reason why
this works. */
free ((void *) waitlist->counterp);
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. I don't think there is
any mechanism that will cause another notification to eventually
deallocate the memory.
But, I ran a testcase (basically identical to the tst-leaks3 that I
posted before) under valgrind and it considers those blocks to be
"possibly lost" rather than the "definitely lost" that I was expecting,
so perhaps there is some internal object that tracks them after all. I
do find all the twisty little data structures involved in
getaddrinfo_a() particularly hard to keep straight in my head so it's
entirely possible I have overlooked something.