gai_cancel()
Phil Blundell
pb@pbcl.net
Fri Jun 16 15:46:00 GMT 2017
According to the Linux manpage for getaddrinfo_a(), the behaviour of
gai_cancel() is as follows:
"The gai_cancel() function cancels the request req.  If the request has
been  canceled  successfully,  the  error  status  of  the request will
be set to EAI_CANCELED and normal asynchronous notification will be
performed."
However, this doesn't seem to match the actual behaviour. From my
tests and inspection of the code, if a request is successfully
cancelled then asynchronous notification is not performed: the request
is simply dropped from the queue. Â This wouldn't in itself be
unreasonable because the application can tell from the return value
whether or not this happened and deal with it appropriately. Initially
I assumed that the code as written was correct and the documentation
was simply missing a crucial "not".
But, it further turns out that if notification is not performed, and
hence __gai_notify is not called, the async_waitlist struct that was
allocated by getaddrinfo_a() is leaked. I've attached a testcase that
demonstrates the leak.
Clearly, changing gai_cancel() to perform notification would make the
code match the documentation and would also fix the memory leak. But
it doesn't seem impossible that there might be applications which are
now relying on the current behaviour and might break if this change
were made. Since getaddrinfo_a() doesn't appear to be part of any
standard, and it also isn't documented in the glibc manual, I wasn't
able to find any other reference that describes what the behaviour is
supposed to be.
Opinions?
thanks
p.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-resolv-tst-leaks3.c-New-test.patch
Type: text/x-patch
Size: 3942 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20170616/b3ae65b2/attachment.bin>
More information about the Libc-alpha
mailing list