Re: gai_cancel()

[Phil Blundell <pb at pbcl dot net>]

On Mon, 2017-06-19 at 13:51 +0200, Florian Weimer wrote:
> How does the memory leak happen?  Would another notification
> eventually
> 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.

p.