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
aurelien@aurel32.net http://www.aurel32.net
Reply to: