Bug#914999: [libc6] Locking problems into libc6
12.12.18 17:11, Roman Savochenko wrote: There are thousands of packages in different versions between Debian 8 and Debian 9. You have found it's not related to the kernel, but I fail to see how that shows it's a libc6 issue. For example when you have tried the kernel from Debian 9 in Debian 8, have you also tried with the rtl8192 firmware from Debian 9? I will compare the firmware, thanks. I have installed of equal package firmware-realtek 20161130-4 on Debian 9 and this problem is actual yet. So, I have found a way of fixing this problem: https://github.com/Mange/rtl8192eu-linux-driver/issues/46 sudo nano /etc/NetworkManager/NetworkManager.conf and add below 2 lines: [device] wifi.scan-rand-mac-address=no Regards, Roman
Bug#914999: [libc6] Locking problems into libc6
Control: severity -1 important On Thu, Nov 29, 2018 at 01:58:47PM +0200, Roman Savochenko wrote: > Package: libc6 > Version: 2.24 > Severity: critical > This is not a critical bug (it's not even clear from the report at this point what the problem is, and it doesn't seem too widespread); downgrading. Cheers, Julien
Processed: Re: Bug#914999: [libc6] Locking problems into libc6
Processing control commands: > severity -1 important Bug #914999 [libc6] [libc6] Locking problems into libc6 Severity set to 'important' from 'critical' -- 914999: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914999 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#914999: [libc6] Locking problems into libc6
Hello, Aurelien
On 12/30/18 7:49 PM, Aurelien Jarno wrote:
On 2018-12-12 17:11, Roman Savochenko wrote:
On 12/4/18 1:24 PM, Roman Savochenko wrote:
On 11/29/18 9:13 PM, Aurelien Jarno wrote:
1. For my program, I was needed to create extra locking about
the function
getaddrinfo(), but that resolved the problem only for my calls
but for the
...
Vice versa, the first problem is actual one for GLibC since:
* I have observed twice the difference, please see on the included
screenshot.
I indeed see two different IPs circled in red. Now I don't get what they
are, if they should be different or not and how that relates to glibc.
The lower IP is addr() used as an argument of the function getaddrinfo():
if(addr_[aOff] != '[') host = TSYS::strParse(addr_, 0, ":", );
else { aOff++; host = TSYS::strParse(addr_, 0, "]:", ); }
//Get IPv6
port = TSYS::strParse(addr_, 0, ":", );
string aErr;
sockFd = -1;
for(int off = 0;
(host_=TSYS::strParse(host,0,",",)).size(); ) {
struct addrinfo hints, *res;
memset(, 0, sizeof(hints));
hints.ai_socktype = (type == SOCK_TCP) ? SOCK_STREAM :
SOCK_DGRAM;
int error;
if(logLen()) pushLogMess(TSYS::strMess(_("Resolving for
'%s'"),host_.c_str()));
MtxAlloc aRes(*SYS->commonLock("getaddrinfo"), true);
if((error=getaddrinfo(host_.c_str(),(port.size()?port.c_str():"10005"),,)))
throw TError(nodePath().c_str(), _("Error the address
'%s': '%s (%d)'"), addr_.c_str(), gai_strerror(error), error);
vector addrs;
for(struct addrinfo *iAddr = res; iAddr != NULL; iAddr =
iAddr->ai_next) {
static struct sockaddr_storage ss;
if(iAddr->ai_addrlen > sizeof(ss)) { aErr = _("sockaddr
to large."); continue; }
memcpy(, iAddr->ai_addr, iAddr->ai_addrlen);
addrs.push_back(ss);
}
freeaddrinfo(res);
aRes.unlock();
Where the top IP is the real one taken from the connection addrs[iA],
the getaddrinfo() result:
//Create socket
if(type == SOCK_TCP) {
if((sockFd=socketsockaddr*)[iA])->sa_family==AF_INET6)?PF_INET6:PF_INET,SOCK_STREAM,0))
== -1)
throw TError(nodePath().c_str(), _("Error
creating the %s socket: '%s (%d)'!"), "TCP", strerror(errno), errno);
int vl = 1; setsockopt(sockFd, SOL_SOCKET,
SO_REUSEADDR, , sizeof(int));
if(MSS()) { vl = MSS(); setsockopt(sockFd,
IPPROTO_TCP, TCP_MAXSEG, , sizeof(int)); }
}
else if(type == SOCK_UDP) {
if((sockFd=socketsockaddr*)[iA])->sa_family==AF_INET6)?PF_INET6:PF_INET,SOCK_DGRAM,0))
== -1)
throw TError(nodePath().c_str(), _("Error
creating the %s socket: '%s (%d)'!"), "UDP", strerror(errno), errno);
}
//Get the connected address
if(((sockaddr*)[iA])->sa_family == AF_INET6) {
char aBuf[INET6_ADDRSTRLEN];
getnameinfo((sockaddr*)[iA],
sizeof(addrs[iA]), aBuf, sizeof(aBuf), 0, 0, NI_NUMERICHOST);
connAddr = aBuf;
} else connAddr =
inet_ntoa(((sockaddr_in*)[iA])->sin_addr);
Then, without the lock "MtxAlloc aRes(*SYS->commonLock("getaddrinfo"),
true);" I have such replacing into and the difference from a
different threaded parallel connection into the same code. And I have up
to ten such parallel connections why I observes this problem!
* Also I have seen once for very long locking into the function
getaddrinfo()->poll() for some VPN (FortiClient in the case), see to
the crash report, got after the program termination by SIGSEGV.
poll() has nothing to do with locking, it just hang there waiting for an
answer to a DNS request sent by the functions called through
getaddrinfo(). According to the trace, the timeout is set to about 5
seconds. The others thread waiting for poll() are called from
libglib-2.0 and from libxcb.so.1.
Sometime, on FortiVPN, the time is forever one and I have more time to
catch this problem sending the signal SIGSEGV and more, once I close the
FortiVPN connection this program successfully finished also.
I think the second poll() is a different case since it is a generic one
function,
As for the segmentation fault, it happens in pthread_cond_timedwait.S
called directly from libQt5Core.so.5. Without more info, it's difficult
to say if it's due to a bug in glibc or if the argument passed to this
function are corrupted, for example because the data pointed by QMutex*
are corrupted. Do you have another way to reproduce the issue that is
actually easier than using openscada?
No, this is also different lock never related with the primary problem.
I have updated the package libc6 up to
Bug#914999: [libc6] Locking problems into libc6
On 2018-12-12 17:11, Roman Savochenko wrote: > Hello, Aurelien > > On 12/4/18 1:24 PM, Roman Savochenko wrote: > > On 11/29/18 9:13 PM, Aurelien Jarno wrote: > > > > 1. For my program, I was needed to create extra locking about > > > > the function > > > > getaddrinfo(), but that resolved the problem only for my calls > > > > but for the > > > > external libraries like to MySQL, MariaDB I yet have the crashes and it > > > > cannot be fixed at all. > > > Can you give more details about the issue, the symptoms, possible crash > > > backtrace, way to reproduce it. Without this details, there are very few > > > chances to be able to fix the bug. > > > > Yes, I had there a crash, but it appeared next as a problem into > > libMariaDB (Bug#915515). Also I had early observed differences into real > > address passed to getaddrinfo() and taken from the real connection, what > > I have not observed now. So this item I remove from causes to GLibC > > problems while. > > Vice versa, the first problem is actual one for GLibC since: > > * I have observed twice the difference, please see on the included >screenshot. I indeed see two different IPs circled in red. Now I don't get what they are, if they should be different or not and how that relates to glibc. > * Also I have seen once for very long locking into the function >getaddrinfo()->poll() for some VPN (FortiClient in the case), see to >the crash report, got after the program termination by SIGSEGV. poll() has nothing to do with locking, it just hang there waiting for an answer to a DNS request sent by the functions called through getaddrinfo(). According to the trace, the timeout is set to about 5 seconds. The others thread waiting for poll() are called from libglib-2.0 and from libxcb.so.1. As for the segmentation fault, it happens in pthread_cond_timedwait.S called directly from libQt5Core.so.5. Without more info, it's difficult to say if it's due to a bug in glibc or if the argument passed to this function are corrupted, for example because the data pointed by QMutex* are corrupted. Do you have another way to reproduce the issue that is actually easier than using openscada? > > There are thousands of packages in different versions between Debian 8 > > > and Debian 9. You have found it's not related to the kernel, but I fail > > > to see how that shows it's a libc6 issue. For example when you have > > > tried the kernel from Debian 9 in Debian 8, have you also tried with the > > > rtl8192 firmware from Debian 9? > > I will compare the firmware, thanks. > I have installed of equal package firmware-realtek 20161130-4 on Debian 9 > and this problem is actual yet. > > > Anyway if we want to know that the problem is related with glibc, please > > > try to install glibc packages (libc*, possibly locales* and nscd if > > > needed) from Debian 9 onto a working Debian 8 installation and see if > > > the problem appears. > > I going to try that also, thanks. > > I have updated the package libc6 up to version 2.24 on Debian 8 and both of > the two last item, RTL8192eu and WIFI HotSpot, continue to work. > > Where can I move then the problems with RTL8192eu and WIFI HotSpot on Debian > 9? The best would be to look the logs in /var/log/syslog to check what is the issue. It could be a dhcp issue, a network-manager issue or a wpasupplicant issue depending what you are using. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#914999: [libc6] Locking problems into libc6
On 11/29/18 9:13 PM, Aurelien Jarno wrote: 1. For my program, I was needed to create extra locking about the function getaddrinfo(), but that resolved the problem only for my calls but for the external libraries like to MySQL, MariaDB I yet have the crashes and it cannot be fixed at all. Can you give more details about the issue, the symptoms, possible crash backtrace, way to reproduce it. Without this details, there are very few chances to be able to fix the bug. Yes, I had there a crash, but it appeared next as a problem into libMariaDB (Bug#915515). Also I had early observed differences into real address passed to getaddrinfo() and taken from the real connection, what I have not observed now. So this item I remove from causes to GLibC problems while. 3. Impossible to connect to any WLan HotSpot (Ad-hoc), for me it is Nokia N9 Without more details, I also fail to see the relation with glibc here. But I do not known other common libraries or build environments (can be GCC for the kernel build) which can be related to such problems with WLan. All those issues fine fork on two Debian 8 installations with the libc6 2.19, where one on the same hardware as Debian 9. Other Debian 9 installation on the stationary PC also does not work for the second issue. Initially I heve counted it is kernel problems but I have installed this same Linux kernel version on Debian 8 and these all work there. There are thousands of packages in different versions between Debian 8 and Debian 9. You have found it's not related to the kernel, but I fail to see how that shows it's a libc6 issue. For example when you have tried the kernel from Debian 9 in Debian 8, have you also tried with the rtl8192 firmware from Debian 9? I will compare the firmware, thanks. Anyway if we want to know that the problem is related with glibc, please try to install glibc packages (libc*, possibly locales* and nscd if needed) from Debian 9 onto a working Debian 8 installation and see if the problem appears. I going to try that also, thanks. Without more information, there is no way for us to fix the bug, so we'll just have to close it. I understand, thanks. Regards, Roman
Bug#914999: [libc6] Locking problems into libc6
control: tag -1 + moreinfo Hi, On 2018-11-29 13:58, Roman Savochenko wrote: > Package: libc6 > Version: 2.24 > Severity: critical > > --- Please enter the report below this line. --- > I have got already more signs of a problem into locking access to functions > like to getaddrinfo(), by the macro __libc_lock_lock, which reproduced in > multithreaded environments! > > 1. For my program, I was needed to create extra locking about the function > getaddrinfo(), but that resolved the problem only for my calls but for the > external libraries like to MySQL, MariaDB I yet have the crashes and it > cannot be fixed at all. Can you give more details about the issue, the symptoms, possible crash backtrace, way to reproduce it. Without this details, there are very few chances to be able to fix the bug. > 2. rtl8192eu by the driver rtl8xxxu, or the external one 8192eu.ko, does not > connect to any network with that messages into dmesg: > [ 137.936642] wlx000f0064f2d8: authenticate with 00:90:4c:08:00:0d > [ 137.940680] wlx000f0064f2d8: send auth to 00:90:4c:08:00:0d (try 1/3) > [ 138.145146] wlx000f0064f2d8: send auth to 00:90:4c:08:00:0d (try 2/3) > [ 138.353198] wlx000f0064f2d8: send auth to 00:90:4c:08:00:0d (try 3/3) > [ 138.557239] wlx000f0064f2d8: authentication with 00:90:4c:08:00:0d timed > out glibc is not involved at all in the wireless driver, so I don't see the relation with the previous issue. > 3. Impossible to connect to any WLan HotSpot (Ad-hoc), for me it is Nokia N9 Without more details, I also fail to see the relation with glibc here. > All those issues fine fork on two Debian 8 installations with the libc6 > 2.19, where one on the same hardware as Debian 9. > Other Debian 9 installation on the stationary PC also does not work for the > second issue. > Initially I heve counted it is kernel problems but I have installed this > same Linux kernel version on Debian 8 and these all work there. There are thousands of packages in different versions between Debian 8 and Debian 9. You have found it's not related to the kernel, but I fail to see how that shows it's a libc6 issue. For example when you have tried the kernel from Debian 9 in Debian 8, have you also tried with the rtl8192 firmware from Debian 9? Anyway if we want to know that the problem is related with glibc, please try to install glibc packages (libc*, possibly locales* and nscd if needed) from Debian 9 onto a working Debian 8 installation and see if the problem appears. Without more information, there is no way for us to fix the bug, so we'll just have to close it. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Processed: Re: Bug#914999: [libc6] Locking problems into libc6
Processing control commands: > tag -1 + moreinfo Bug #914999 [libc6] [libc6] Locking problems into libc6 Added tag(s) moreinfo. -- 914999: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914999 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#914999: [libc6] Locking problems into libc6
Package: libc6 Version: 2.24 Severity: critical --- Please enter the report below this line. --- I have got already more signs of a problem into locking access to functions like to getaddrinfo(), by the macro __libc_lock_lock, which reproduced in multithreaded environments! 1. For my program, I was needed to create extra locking about the function getaddrinfo(), but that resolved the problem only for my calls but for the external libraries like to MySQL, MariaDB I yet have the crashes and it cannot be fixed at all. 2. rtl8192eu by the driver rtl8xxxu, or the external one 8192eu.ko, does not connect to any network with that messages into dmesg: [ 137.936642] wlx000f0064f2d8: authenticate with 00:90:4c:08:00:0d [ 137.940680] wlx000f0064f2d8: send auth to 00:90:4c:08:00:0d (try 1/3) [ 138.145146] wlx000f0064f2d8: send auth to 00:90:4c:08:00:0d (try 2/3) [ 138.353198] wlx000f0064f2d8: send auth to 00:90:4c:08:00:0d (try 3/3) [ 138.557239] wlx000f0064f2d8: authentication with 00:90:4c:08:00:0d timed out 3. Impossible to connect to any WLan HotSpot (Ad-hoc), for me it is Nokia N9 All those issues fine fork on two Debian 8 installations with the libc6 2.19, where one on the same hardware as Debian 9. Other Debian 9 installation on the stationary PC also does not work for the second issue. Initially I heve counted it is kernel problems but I have installed this same Linux kernel version on Debian 8 and these all work there. --- System information. --- Architecture: Kernel: Linux 4.9.0-6-amd64 Debian Release: 9.5 500 stable-updates ftp.ua.debian.org 500 stable security.debian.org 500 stable linux.teamviewer.com 500 stable ftp.ua.debian.org 500 preview linux.teamviewer.com 100 stretch-backports ftp.ua.debian.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty.
