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
