Unexpected netlink response of size <number> on descriptor <number>

Abhi Arora engr.abhiarora@gmail.com
Fri Dec 20 04:46:00 GMT 2019

Thank you for your answer. However, I want to understand this
"descriptor race". You mean if any application is also using the
netlink descriptor along with getaddrinfo() ?.

I think what you mean is "If my application opens and closes a netlink
socket descriptor (say it is 5) and even after closing it, it reuses
that file descriptor for further operations. However, in the meantime,
getaddrinfo() was called and it opens a netlink descriptor. Since,
kernel returns lowest free file descriptor number, it may return 5.
Now, two parts of an application are using the same file descriptor
and hence, data send by application could be received by netlink
descriptor opened by getaddrinfo() or vice-verse. Hence, I have
received that error message  "Uxpected error 9 on netlink descriptor
6" ".

Please correct me if I am wrong.
Thank you.

On Fri, Dec 20, 2019 at 12:01 AM Florian Weimer <fweimer@redhat.com> wrote:
> * Abhi Arora:
> > I have seen SIGABRT in my multi-threaded application deployed in Linux
> > machine. The message that I got over stderr was "Uxpected error 9 on
> > netlink descriptor 6".
> >
> > While googling, I came across this link:
> > https://lists.gnu.org/archive/html/info-gnu/2016-02/msg00009.html
> >
> > I want to under the following lines
> > "The most likely cause for these errors is a multi-threaded
> > application which erroneously closes and reuses the netlink file
> > descriptor while it is used by getaddrinfo."
> >
> > I am not using "netlink" socket in my application but it seems
> > libraries that I am using (Poco, curl) might be calling "getaddrinfo".
> > Please help me in understanding the above lines and if possible with a
> > direction to resolve this issue.
> The netlink socket is internal to glibc (specifically, getaddrinfo).
> If the application or any of its libraries has any descriptor race (it
> does not matter if it is a socket, file or directory) and calls
> getaddrinfo, it can encounter the abort.
> Thanks,
> Florian

More information about the Libc-help mailing list