Processed: bug 1006764 is forwarded to https://sourceware.org/bugzilla/show_bug.cgi?id=27653
Processing commands for cont...@bugs.debian.org: > forwarded 1006764 https://sourceware.org/bugzilla/show_bug.cgi?id=27653 Bug #1006764 [libc6] libc6: i18n causes deadlocks with malloc interposers like libasan (AddressSanitizer) Ignoring request to change the forwarded-to-address of bug#1006764 to the same value > thanks Stopping processing here. Please contact me if you need assistance. -- 1006764: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006764 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: affects 1006764
Processing commands for cont...@bugs.debian.org: > affects 1006764 libasan6 Bug #1006764 [libc6] libc6: i18n causes deadlocks with malloc interposers like libasan (AddressSanitizer) Added indication that 1006764 affects libasan6 > thanks Stopping processing here. Please contact me if you need assistance. -- 1006764: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006764 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1006764: libc6: i18n causes deadlocks with malloc interposers like libasan (AddressSanitizer)
Package: libc6 Version: 2.33-7 Severity: normal Tags: upstream Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=27653 Affects: libasan6 This has been reported upstream, but let's give it more visibility (this could save hours of debugging...). In short, using LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6 with some executables can make the executable hang. Examples: With LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6 inkscape Thread 1 (Thread 0x7f07770c8bc0 (LWP 424733) "inkscape"): #0 __futex_abstimed_wait_common64 (futex_word=futex_word@entry=0x7f077dd21be8 <_nl_state_lock+8>, expected=expected@entry=2, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=false) at ../sysdeps/nptl/futex-internal.c:87 err = -512 op = 393 #1 0x7f077db3f148 in __GI___futex_abstimed_wait64 (futex_word=futex_word@entry=0x7f077dd21be8 <_nl_state_lock+8>, expected=expected@entry=2, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:112 #2 0x7f077db37ad5 in __pthread_rwlock_wrlock_full64 (abstime=0x0, clockid=0, rwlock=0x7f077dd21be0 <_nl_state_lock>) at pthread_rwlock_common.c:829 private = 0 err = may_share_futex_used_flag = wpf = ready = false r = result = #3 __GI___pthread_rwlock_wrlock (rwlock=0x7f077dd21be0 <_nl_state_lock>) at pthread_rwlock_wrlock.c:27 result = #4 0x7f077db8375e in set_binding_values (domainname=0x7f077b8be5b7 "gspell-1", dirnamep=0x0, codesetp=0x7ffdaf37e428) at bindtextdom.c:91 __p = binding = modified = #5 0x7f077db83bd1 in set_binding_values (codesetp=0x7ffdaf37e428, dirnamep=0x0, domainname=) at bindtextdom.c:82 [...] and with LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6 vlc Thread 1 (Thread 0x7f2f9be09340 (LWP 424824) "vlc"): #0 __futex_abstimed_wait_common64 (futex_word=futex_word@entry=0x7f2f9c651be8 <_nl_state_lock+8>, expected=expected@entry=2, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=false) at ../sysdeps/nptl/futex-internal.c:87 clockbit = err = -512 op = 393 #1 0x7f2f9c675148 in __GI___futex_abstimed_wait64 (futex_word=futex_word@entry=0x7f2f9c651be8 <_nl_state_lock+8>, expected=expected@entry=2, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:112 No locals. #2 0x7f2f9c66dad5 in __pthread_rwlock_wrlock_full64 (abstime=0x0, clockid=0, rwlock=0x7f2f9c651be0 <_nl_state_lock>) at pthread_rwlock_common.c:829 private = 0 err = may_share_futex_used_flag = wpf = ready = false r = may_share_futex_used_flag = r = done = wpf = ready = __value = prefer_writer = private = wf = err = w = w = private = err = w = wf = wf = __value = #3 __GI___pthread_rwlock_wrlock (rwlock=0x7f2f9c651be0 <_nl_state_lock>) at pthread_rwlock_wrlock.c:27 result = #4 0x7f2f9c4b375e in set_binding_values (domainname=0x7f2f9c2f666b "vlc", dirnamep=0x0, codesetp=0x7fff24056378) at bindtextdom.c:91 __p = binding = modified = [...] and similarly with gnuplot: Thread 1 (Thread 0x7fbcf39e4bc0 (LWP 424576) "gnuplot"): #0 __futex_abstimed_wait_common64 (futex_word=futex_word@entry=0x7fbcf8be8be8 <_nl_state_lock+8>, expected=expected@entry=2, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=false) at ../sysdeps/nptl/futex-internal.c:87 err = -512 op = 393 #1 0x7fbcf8c06148 in __GI___futex_abstimed_wait64 (futex_word=futex_word@entry=0x7fbcf8be8be8 <_nl_state_lock+8>, expected=expected@entry=2, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:112 #2 0x7fbcf8bfead5 in __pthread_rwlock_wrlock_full64 (abstime=0x0, clockid=0, rwlock=0x7fbcf8be8be0 <_nl_state_lock>) at pthread_rwlock_common.c:829 private = 0 err = may_share_futex_used_flag = wpf = ready = false r = result = #3 __GI___pthread_rwlock_wrlock (rwlock=0x7fbcf8be8be0 <_nl_state_lock>) at pthread_rwlock_wrlock.c:27 result = #4 0x7fbcf8a4a75e in set_binding_values (domainname=0x7fbcf7de4f51 "gtk30-properties", dirnamep=0x7fff4f41f848, codesetp=0x0) at bindtextdom.c:91 __p = binding = modified = [...] -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
Bug#987266: preinst check for kernel release > 255 may no longer be needed
On 2022-03-04 10:22, Emilio Pozuelo Monfort wrote: > On 04/03/2022 09:50, Aurelien Jarno wrote: > > On 2022-03-04 09:19, Emilio Pozuelo Monfort wrote: > > > Hi, > > > > > > On Sun, 26 Sep 2021 09:57:02 +0200 Salvatore Bonaccorso > > > wrote: > > > > Hi Aurelien, > > > > > > > > On Tue, Apr 20, 2021 at 06:36:33PM +0200, Andras Korn wrote: > > > > > Package: libc6 > > > > > Version: 2.31-11 > > > > > Severity: normal > > > > > > Hi, > > > > > > due to > > > > > https://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f > > > > > (a commit from 2004) the preinst script for glibc checks whether the > > > > > "z" in the "x.y.z" of the kernel version is less than 255. If yes, > > > > > the package refuses to install. > > > > > > I hit this problem on a box with a custom 4.9.266 kernel. > > > > > > Based on this lkml thread: > > > > > https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/, > > > > > the check is no longer needed because the kernel caps the version > > > > > code it reports to 255, even if uname prints a higher number. > > > > > > Of course, you could conceivably still hit the problem with earlier > > > > > kernels, so I suppose the logic of the check should be modified, not > > > > > removed entirely, to be technically correct. > > > > > > If forced at gunpoint to make a guess, I would guess, though, that > > > > > removing the check would have very little actual impact; it also > > > > > doesn't protect the user from installing a kernel with an > > > > > unsupported version number after having installed glibc. > > > > > > > > Prompted by > > > > https://lore.kernel.org/stable/yvaholtsb0nk0...@kroah.com/T/#t and > > > > given this was addressed with > > > > https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900 > > > > is this something we should do consider as well for the older releases > > > > where it is not acutally needed for people compiling their own custom > > > > kernels? > > > > > > Another stretch user brought this up [1]. I suppose there are and as time > > > passes (with current stable kernel versions getting higher) there will be > > > more users affected by this in buster and bullseye. Have you further > > > considered including this fix in a proposed-update? > > > > Yep I have submitted #1005906 for bullseye, and I have committed the fix > > to the buster branch, but not yet submitted the bug. > > I was wondering what docker had to do with all this, until I realized you > meant #1005949 :) Oops, sorry about that. > > Stretch is going to be more complicated as we still support 2.6.32 > > kernels, which means the third version level actually still makes sense. > > I'm surprised we support that. However in any case we wouldn't need to We disabled it at some point but we got strong pressure to re-enable it as it is the last version supported by OpenVZ. > backport [1], we could just backport [2] and support both 2.6.32 as well as > e.g. 4.14.264. Wouldn't that work? If we backport only [2], it means [1] doesn't work correctly as it assumes that the third version level is < 255, just like glibc internals. Aurelien > [1] > https://salsa.debian.org/glibc-team/glibc/-/commit/5452b62ded81132ebedf3db82577de5277479b27 > [2] > https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#987266: preinst check for kernel release > 255 may no longer be needed
On 04/03/2022 09:50, Aurelien Jarno wrote: On 2022-03-04 09:19, Emilio Pozuelo Monfort wrote: Hi, On Sun, 26 Sep 2021 09:57:02 +0200 Salvatore Bonaccorso wrote: Hi Aurelien, On Tue, Apr 20, 2021 at 06:36:33PM +0200, Andras Korn wrote: Package: libc6 Version: 2.31-11 Severity: normal Hi, due to https://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f (a commit from 2004) the preinst script for glibc checks whether the "z" in the "x.y.z" of the kernel version is less than 255. If yes, the package refuses to install. I hit this problem on a box with a custom 4.9.266 kernel. Based on this lkml thread: https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/, the check is no longer needed because the kernel caps the version code it reports to 255, even if uname prints a higher number. Of course, you could conceivably still hit the problem with earlier kernels, so I suppose the logic of the check should be modified, not removed entirely, to be technically correct. If forced at gunpoint to make a guess, I would guess, though, that removing the check would have very little actual impact; it also doesn't protect the user from installing a kernel with an unsupported version number after having installed glibc. Prompted by https://lore.kernel.org/stable/yvaholtsb0nk0...@kroah.com/T/#t and given this was addressed with https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900 is this something we should do consider as well for the older releases where it is not acutally needed for people compiling their own custom kernels? Another stretch user brought this up [1]. I suppose there are and as time passes (with current stable kernel versions getting higher) there will be more users affected by this in buster and bullseye. Have you further considered including this fix in a proposed-update? Yep I have submitted #1005906 for bullseye, and I have committed the fix to the buster branch, but not yet submitted the bug. I was wondering what docker had to do with all this, until I realized you meant #1005949 :) Stretch is going to be more complicated as we still support 2.6.32 kernels, which means the third version level actually still makes sense. I'm surprised we support that. However in any case we wouldn't need to backport [1], we could just backport [2] and support both 2.6.32 as well as e.g. 4.14.264. Wouldn't that work? Cheers, Emilio [1] https://salsa.debian.org/glibc-team/glibc/-/commit/5452b62ded81132ebedf3db82577de5277479b27 [2] https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900
Bug#987266: preinst check for kernel release > 255 may no longer be needed
On 2022-03-04 09:19, Emilio Pozuelo Monfort wrote: > Hi, > > On Sun, 26 Sep 2021 09:57:02 +0200 Salvatore Bonaccorso > wrote: > > Hi Aurelien, > > > > On Tue, Apr 20, 2021 at 06:36:33PM +0200, Andras Korn wrote: > > > Package: libc6 > > > Version: 2.31-11 > > > Severity: normal > > > > Hi, > > > > due to > > > https://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f > > > (a commit from 2004) the preinst script for glibc checks whether the > > > "z" in the "x.y.z" of the kernel version is less than 255. If yes, > > > the package refuses to install. > > > > I hit this problem on a box with a custom 4.9.266 kernel. > > > > Based on this lkml thread: > > > https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/, > > > the check is no longer needed because the kernel caps the version > > > code it reports to 255, even if uname prints a higher number. > > > > Of course, you could conceivably still hit the problem with earlier > > > kernels, so I suppose the logic of the check should be modified, not > > > removed entirely, to be technically correct. > > > > If forced at gunpoint to make a guess, I would guess, though, that > > > removing the check would have very little actual impact; it also > > > doesn't protect the user from installing a kernel with an > > > unsupported version number after having installed glibc. > > > > Prompted by > > https://lore.kernel.org/stable/yvaholtsb0nk0...@kroah.com/T/#t and > > given this was addressed with > > https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900 > > is this something we should do consider as well for the older releases > > where it is not acutally needed for people compiling their own custom > > kernels? > > Another stretch user brought this up [1]. I suppose there are and as time > passes (with current stable kernel versions getting higher) there will be > more users affected by this in buster and bullseye. Have you further > considered including this fix in a proposed-update? Yep I have submitted #1005906 for bullseye, and I have committed the fix to the buster branch, but not yet submitted the bug. Stretch is going to be more complicated as we still support 2.6.32 kernels, which means the third version level actually still makes sense. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#987266: preinst check for kernel release > 255 may no longer be needed
Hi, On Sun, 26 Sep 2021 09:57:02 +0200 Salvatore Bonaccorso wrote: Hi Aurelien, On Tue, Apr 20, 2021 at 06:36:33PM +0200, Andras Korn wrote: > Package: libc6 > Version: 2.31-11 > Severity: normal > > Hi, > > due to > https://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f > (a commit from 2004) the preinst script for glibc checks whether the > "z" in the "x.y.z" of the kernel version is less than 255. If yes, > the package refuses to install. > > I hit this problem on a box with a custom 4.9.266 kernel. > > Based on this lkml thread: > https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/, > the check is no longer needed because the kernel caps the version > code it reports to 255, even if uname prints a higher number. > > Of course, you could conceivably still hit the problem with earlier > kernels, so I suppose the logic of the check should be modified, not > removed entirely, to be technically correct. > > If forced at gunpoint to make a guess, I would guess, though, that > removing the check would have very little actual impact; it also > doesn't protect the user from installing a kernel with an > unsupported version number after having installed glibc. Prompted by https://lore.kernel.org/stable/yvaholtsb0nk0...@kroah.com/T/#t and given this was addressed with https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900 is this something we should do consider as well for the older releases where it is not acutally needed for people compiling their own custom kernels? Another stretch user brought this up [1]. I suppose there are and as time passes (with current stable kernel versions getting higher) there will be more users affected by this in buster and bullseye. Have you further considered including this fix in a proposed-update? Cheers, Emilio [1] https://lists.debian.org/debian-lts/2022/03/msg2.html
