Bug#924712: crypt() not available _XOPEN_SOURCE is defined
On Sun, 25 Aug 2019 15:51:21 +0200 Francesco Poli wrote: > On Sun, 25 Aug 2019 13:46:36 +0200 Florian Weimer wrote: [...] > > We provided a solution acceptable to the reporter. I do not think > > further action is needed on the glibc side. The manual page needs to > > be updated to reflect the change, but that's not part of glibc. > > OK, good. > Thanks for your prompt reply! > > Why is the bug report being kept open, though? > Should it be reassigned to package manpages-dev and fixed there? If you do not object (by the end of August), I can reassign the bug report to package manpages-dev. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpx9QUCGCKSs.pgp Description: PGP signature
Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster
* Pavel Matěja: > Sorry for late answer. > > On 17. 08. 19 22:18, Florian Weimer wrote: >> * Pavel Matěja: >> >>> The strange means they appear only on 2 servers out of 6. >>> Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon >>> E3-1220 v6 produced crashes. >>> It did not matter if the host Debian was Stretch or Buster. >> Do you see crashes on stretch as well? What does the backtrace look >> like there? > I newer saw the SEGFAULT when we had Stretch based chroot. > > I had just one SEGFAULT on Stretch host but I didn't collect coredumps > back then. > Unfortunately the server is already running Buster. > Since the bug is caused by new libc in chroot I should be able to > install just kernel from Stretch and wait for the SEGFAULT, right? > I think the backtrace will be the same anyway. If I recall correctly, stretch doesn't have the tcache code. If the crash happened there as well, it's something else. >>> SSLv3 and TLS code path looked quite distinct to cause the same problem. >>> Based on info that SEGFAULTs are related to memory allocation in new >>> libc and CPU performance I found >>> http://51.15.138.76/patch/17499/ >>> where Wilco Dijkstra discuss some problems with tcache which "leads to >>> various crashes in benchtests" >> I was under the impression that this problem only occurs if one of the >> tunables has an out-of-bounds value. Do you set any tunables? > No, I didn't even know they existed. > I did not read the libc sources yet so I don't know what does the > patch actually fixes neither if it helps with my problem. Then the patch will not help to fix the crash. (By the way, even if the crash goes away if you use a tunable to disable the thread cache, it could still be timing-related. It's definitely possible that the faster malloc/free implementation exposes pre-existing data races.) Thanks, Florian
Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster
Sorry for late answer. On 17. 08. 19 22:18, Florian Weimer wrote: * Pavel Matěja: The strange means they appear only on 2 servers out of 6. Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon E3-1220 v6 produced crashes. It did not matter if the host Debian was Stretch or Buster. Do you see crashes on stretch as well? What does the backtrace look like there? I newer saw the SEGFAULT when we had Stretch based chroot. I had just one SEGFAULT on Stretch host but I didn't collect coredumps back then. Unfortunately the server is already running Buster. Since the bug is caused by new libc in chroot I should be able to install just kernel from Stretch and wait for the SEGFAULT, right? I think the backtrace will be the same anyway. SSLv3 and TLS code path looked quite distinct to cause the same problem. Based on info that SEGFAULTs are related to memory allocation in new libc and CPU performance I found http://51.15.138.76/patch/17499/ where Wilco Dijkstra discuss some problems with tcache which "leads to various crashes in benchtests" I was under the impression that this problem only occurs if one of the tunables has an out-of-bounds value. Do you set any tunables? No, I didn't even know they existed. I did not read the libc sources yet so I don't know what does the patch actually fixes neither if it helps with my problem. Pavel Matěja
