Description of problem:
The recvmsg system calls for netlink sockets have been particularly
prone to picking up unrelated data after a file descriptor race
(where the descriptor is closed and reopened concurrently in a
multi-threaded process, as the result of a file descriptor management
Version-Release number of selected component (if applicable):
RHEL6.0 - RHEL6.10 Errata Latest (glibc-2.12-1.209.el6)
Steps to Reproduce:
1. Multi-threaded JavaAP create many SNMP4J instance.
2. A thread is spinning forever.
#0 0xf7717430 in __kernel_vsyscall ()
#1 0xf757e448 in recvmsg () at ../sysdeps/unix/sysv/linux/i386/socket.S:97
#2 0xf76797a6 in make_request (fd=1590, pid=<value optimized out>, seen_ipv4=0x7dceea7b, seen_ipv6=0x7dceea7a, in6ai=0x7dceea70, in6ailen=0x7dceea6c) at ../sysdeps/unix/sysv/linux/check_pf.c:123
#3 0xf7679bd4 in __check_pf (seen_ipv4=0x7dceea7b, seen_ipv6=0x7dceea7a, in6ai=0x7dceea70, in6ailen=0x7dceea6c) at ../sysdeps/unix/sysv/linux/check_pf.c:275
#4 0xf761ff4c in getaddrinfo (name=0x988f330 "<a-valid-host-name>", service=0x0, hints=0x7dceeaf8, pai=0x7dceeb18) at ../sysdeps/posix/getaddrinfo.c:2109
A thread is spinning forever.
All threads are not spining forever.
(2016-02-19 glibc-2.23 release)
I'm afraid, but this kind of change is not appropriate during Production Phase 2 of Red Hat Enterprise Linux 6. We will consider it for Red Hat Enterprise Linux 7.
(In reply to Florian Weimer from comment #2)
> I'm afraid, but this kind of change is not appropriate during Production
> Phase 2 of Red Hat Enterprise Linux 6. We will consider it for Red Hat
> Enterprise Linux 7.
I hope the Errata package will be released as soon as possible.
I understood that the glibc problem will be fixed by at least RHEL7.5,
and the circumstances (no fix for Production Phase 2) of RHEL 6.
But, I hope the Errata package for RHEL6.x
(In reply to Masaki MAENO from comment #5)
> But, I hope the Errata package for RHEL6.x
But other users of Red Hat Enterprise Linux 6 expect that their buggy applications continue to run, even if that means burning CPU cycles in an infinite loop.
The situation is different for Red Hat Enterprise Linux 7 because the product is still relatively early in its life-cycle.
(In reply to Florian Weimer from comment #6)
I understood that there is no choice but to avoid the problem by serializing getaddrinfo() in the multi-threaded application on RHEL6.
(In reply to Masaki MAENO from comment #7)
> I understood that there is no choice but to avoid the problem by serializing
> getaddrinfo() in the multi-threaded application on RHEL6.
The libresolv bug which could trigger incorrect file descriptor reuse in getaddrinfo was addressed in this erratum:
If the application has a different descriptor reuse issue, serializing calls to getaddrinfo will probably be insufficient to avoid the bug.
(In reply to Florian Weimer from comment #8)
Thank you for the errata infomation.
But, we use glibc-2.12-1.209.el6 that is newer than glibc-2.12-1.149.el6_6.7,
so I think there is the problem of getaddrinfo() stuck.
(In reply to Masaki MAENO from comment #9)
> Thank you for the errata infomation.
> But, we use glibc-2.12-1.209.el6 that is newer than
> so I think there is the problem of getaddrinfo() stuck.
In this case, please open a support case:
Note that this could also be an issue with your application. File descriptor races are somewhat common, and our erratum only fixed an issue within glibc itself, which is why it does not help to deal with application bugs.
I think this bug will fix it at RHEL 7.5.
Is my recognition recognized properly?
(In reply to Masaki MAENO from comment #11)
> I think this bug will fix it at RHEL 7.5.
> Is my recognition recognized properly?
Have you opened a support case (see comment 10)? Please keep in mind that the changed discussed in this bug is merely a diagnostic aid for broken applications. If an application triggers the diagnostic, it will still have to be fixed.
I asked the customer to register the support case.
Core fix is in glibc-2.17-276.el7. glibc-2.17-279.el7 brings a minor improvement in error message formatting.
Verified, SanityOnly, the patch was successfully applied
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.