Bug#1019354: libc6-dev-riscv64-cross: static libc is unusable
Package: libc6-dev-riscv64-cross
Version: 2.34-7cross2
Severity: important
Dear Maintainer,
Even the most trivial C program:
encounters a segmentation crash when linked statically:
# cat << EOF > hello.c
int main(void) { return 0; }
EOF
# riscv64-linux-gnu-gcc -O2 -static hello.c
# qemu-riscv64-static ./a.out
This can be verified both by running the resulting binary under
qemu-riscv64-static or on real RISC-V hardware running the Debian
RISC-V port.
On target hardware, I can get a stack trace in early libc code:
$ gdb ./a.out
GNU gdb (Debian 12.1-3) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "riscv64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Bug#1008174: libc6: poll() spuriously returns EINTR
Hi, Le lauantaina 26. maaliskuuta 2022, 21.34.38 EET Aurelien Jarno a écrit : > > As far as I understand, POSIX allows (or even requires) thread > > cancellation to be essentially like a signal interruption, save for > > ending the thread. But that is *only* from the moment that cancellation > > is effected. Cancellation cannot be effected while it is disabled by > > definition, so the behaviour from glibc seems wrong here. > > poll() is a cancellation point. It appears to me that POSIX actually > allows this behaviour for cancellation points: I don't think so... > "The side effects of acting upon a cancellation request while suspended > during a call of a function are the same as the side effects that may be > seen in a single-threaded program when a call to a function is > interrupted by a signal and the given function returns [EINTR]. Any such > side effects occur before any cancellation cleanup handlers are called." AFAIU, in POSIX, "acting upon" a cancellation request means to move the cancellation request past the pending state, in other words, actually cancel the thread. That quote clarifies that the signal-like interruption is observed in the cancelled thread flow of execution before the cancellation clean-up handlers. Otherwise the next paragraph would not make much sense, particularly the last sentence: > "Whenever a thread has cancelability enabled and a cancellation request has > been made with that thread as the target, and the thread then calls any > function that is a cancellation point (such as pthread_testcancel() or > read()), the cancellation request shall be acted upon before the function > returns. If a thread has cancelability enabled and a cancellation request is > made with the thread as a target while the thread is suspended at a > cancellation point, the thread shall be awakened and the cancellation > request shall be acted upon." > "However, if the thread is suspended at a cancellation point and the event > for which it is waiting occurs before the cancellation request is acted > upon, it is unspecified whether the cancellation request is acted upon or > whether the cancellation request remains pending and the thread resumes > normal execution." And it would get even more nonsensical / contradictory in the following section: > "When a cancellation request is acted upon, (...) the thread first disables > cancellation by setting its cancelability state to PTHREAD_CANCEL_DISABLE > and its cancelability type to PTHREAD_CANCEL_DEFERRED. The cancelability > state shall remain set to PTHREAD_CANCEL_DISABLE until the thread has > terminated." This paragraph clarifies that cancellation cannot occur recursively / more than once per thread. Assuming that "acting upon a cancellation request" would be permissible with cancellation disabled, this sentence would imply that cancellation is disabled permanently, and the thread will never get cancelled at all. -- Rémi Denis-Courmont http://www.remlab.net/
Bug#1008174: libc6: poll() spuriously returns EINTR
Package: libc6
Version: 2.34-0experimental3
Severity: important
Dear Maintainer,
In the example below, glibc 2.34 from experimental causes a spurious
EINTR error in the poll() call from the child thread. It seems that
thread cancellation causes the poll() to be spuriously interrupted,
even though the cancellation is explicitly disabled at that time.
As far as I understand, POSIX allows (or even requires) thread
cancellation to be essentially like a signal interruption, save for
ending the thread. But that is *only* from the moment that cancellation
is effected. Cancellation cannot be effected while it is disabled by
definition, so the behaviour from glibc seems wrong here.
This regression is known to break the test suite from the VLC package.
Rolling back to 2.33 from unstable solves the problem.
8<
#include
#include
#include
#include
#include
#include
static void *thread(void *data)
{
int canc;
(void) data;
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, );
if (poll(NULL, 0, 2000) < 0) {
perror("Unexpected poll error");
abort();
}
pthread_setcancelstate(canc, NULL);
return NULL;
}
int main(void)
{
pthread_t th;
void *ret;
struct timespec ts = { 0, 100*1000*1000 };
if (pthread_create(, NULL, thread, NULL)) {
perror("pthread_create");
return 1;
}
clock_nanosleep(CLOCK_MONOTONIC, 0, , NULL);
pthread_cancel(th);
pthread_join(th, );
assert(ret == NULL);
return 0;
}
>8
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64
Kernel: Linux 5.16.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to fi_FI.UTF-8), LANGUAGE=fr:en_GB:fi
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libc6 depends on:
ii libgcc-s1 12-20220319-1
Versions of packages libc6 recommends:
ii libidn2-0 2.3.2-2
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.79
pn glibc-doc
ii libc-l10n 2.34-0experimental3
ii libnss-nis 3.1-4
ii libnss-nisplus 1.3-4
ii locales2.33-7
-- debconf information:
* libraries/restart-without-asking: true
glibc/kernel-too-old:
glibc/restart-services:
glibc/kernel-not-supported:
glibc/restart-failed:
* glibc/upgrade: true
glibc/disable-screensaver:
Bug#551903: libc6-i686 pthread_cond_wait fails to reacquire mutex upon cancellation
Le jeudi 3 juin 2010 00:32:14 Aurelien Jarno, vous avez écrit : Does it mean it's a lot more difficult to reproduce it with this version? Today the test case failed 3 out of 3 times already. My VLC debug builds started triggering pthread_mutex_unlock() errors pseudo-randomly again. I did not observe this behaviour since you had presumably fixed the bug. Not a single occurence in those many months. Have you tried to run so many iterations with the version built with gcc-4.3? The test case, not that I remember. VLC debug builds, yes. % cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping: 4 cpu MHz : 2800.000 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid xtpr bogomips: 5585.95 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 32 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping: 4 cpu MHz : 2800.000 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid xtpr bogomips: 5586.01 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 32 bits virtual power management: -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006032059.23141.r...@remlab.net
Bug#551903: libc6-i686 pthread_cond_wait fails to reacquire mutex upon cancellation
Le jeudi 3 juin 2010 22:00:13 Aurelien Jarno, vous avez écrit : I have found a machine with almost the same CPU, the only difference being the speed (3.00 GHz instead of 2.80 GHz). I am unable to reproduce the problem, I have run the testcase more than 20 times over last night. With SMT (HyperThread) support? Maybe the problem is actually not in the GNU libc. What kernel are you running? Normally, I use upstream 2.6.32.15 at the moment. But I also hit the bug with Debian 2.6.32-5-686. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006032209.49649.r...@remlab.net
Bug#551903: libc6-i686 pthread_cond_wait fails to reacquire mutex upon cancellation
Le mardi 1 juin 2010 20:20:01 Aurelien Jarno, vous avez écrit : I am therefore reopening this bug as it may still be present, though we now have a different version and a different compiler. As I am unable to reproduce the original problem, I am unable to test this new version. Could you please test if version 2.11.1-2 is affected or not? It is. I hit the failure case after 8074 consecutive iterations. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006022328.52885.r...@remlab.net
Bug#551903: libc6-i686 pthread_cond_wait fails to reacquire mutex upon cancellation
Le lundi 26 octobre 2009 10:10:45 Aurelien Jarno, vous avez écrit : I'm running on a single core SMT (P4/HT namely), so instruction cycle timing might be very different from what an UP or non-SMT SMP gets :( In any case, the fact that is only occurs with libc6-i686 hints at incorrect use of atomic ops, I guess... Problems related to atomic ops often comes, or at least are triggered by, gcc changes. I have rebuilt eglibc 2.10.1-2 using gcc-4.3 instead of gcc-4.4. The packages are available on http://temp.aurel32.net/eglibc/ Could you please tell me if you have the same problem with them? Good catch. I could not reproduce the problem with 2.10.1-2+gcc4.3, neither with the test case nor with VLC media player. Thanks! -- Rémi Denis-Courmont http://www.remlab.net/ -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551903: libc6-i686 pthread_cond_wait fails to reacquire mutex upon cancellation
Le mercredi 21 octobre 2009 22:33:56, vous avez écrit : On Wed, Oct 21, 2009 at 07:11:40PM +0300, Remi Denis-Courmont wrote: Package: libc6-i686 Version: 2.10.1-1 Severity: critical Justification: breaks unrelated software Hello, With the upgrade to 2.10.1, pthread_cond_wait() fails to re-acquire the provided mutex when acting on a deferred cancellation event from another thread. This is seen if (and apparently, only if) another thread acquires the same mutex after cancellation is initiated, but before the cancelled thread executes cancellation cleanup handlers. I could not reproduce the problem with plain libc6. It only occurs with libc6-i686 installed. I wrote a simple test case at: http://www.remlab.net/files/divers/condfail.c This test shows the same behaviour on both lenny and sid version, that is it prints 1 and 2, but never triggers an assertion. Are there other conditions for this test to fail? I don't know. It reproduces pretty much 100% here: % ./a.out 1 2 a.out: test.c:18: cleanup_lock: Assertion `val == 0' failed. Abandon I'm running on a single core SMT (P4/HT namely), so instruction cycle timing might be very different from what an UP or non-SMT SMP gets :( In any case, the fact that is only occurs with libc6-i686 hints at incorrect use of atomic ops, I guess... -- Rémi Denis-Courmont http://www.remlab.net/ -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#443660: New test case for #443660
Le Sunday 16 December 2007 12:58:16 Pierre Habouzit, vous avez écrit : notfound 443660 2.7-4 thanks On Sat, Dec 15, 2007 at 07:35:36PM +, Rémi Denis-Courmont wrote: found 443660 2.7-4 thanks Hello, Seems like the original test case does not crash anymore. I still have problems with this one new though - it crashes pseudorandomly (about 10% crashes here). Unfortunately, I have not been able to reproduce the problem under a debugger. Interestingly, I once had the crash with the first error message in C locale: I completely fail to see why it's the same bug, in fact I'm almost sure it's not. And without a backtrace I'm unsure what we can do about it. Please open a new bug instead of diverting old bugs from their purpose. Connexion terminée par Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x86bd0b90 (LWP 10614)] 0xb7e599d8 in strcmp () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7e599d8 in strcmp () from /lib/i686/cmov/libc.so.6 #1 0xb7e0d473 in _nl_find_msg () from /lib/i686/cmov/libc.so.6 #2 0xb7e0e122 in __dcigettext () from /lib/i686/cmov/libc.so.6 #3 0xb7e0ceb3 in dcgettext () from /lib/i686/cmov/libc.so.6 #4 0xb7e59ee9 in strerror_r () from /lib/i686/cmov/libc.so.6 #5 0xb7e27c9f in vfprintf () from /lib/i686/cmov/libc.so.6 #6 0xb7e4a874 in vsnprintf () from /lib/i686/cmov/libc.so.6 #7 0xb7e2f1d5 in snprintf () from /lib/i686/cmov/libc.so.6 #8 0x080485f0 in run () #9 0xb7f3a4fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #10 0xb7ebe60e in clone () from /lib/i686/cmov/libc.so.6 Looks like exactly the same problem to me. -- Rémi Denis-Courmont http://www.remlab.net/ signature.asc Description: This is a digitally signed message part.
Bug#456531: libc6: strerror_r() not thread-safe
Subject: libc6: strerror_r() not thread-safe
Package: libc6
Version: 2.7-4
Severity: important
Hello,
strerror_r() crashes pseudo-randomly when multiple threads invoke it
simultaneously. It appears the problem never occurs when using the C/POSIX
locale, and seems to be gettext-related.
Test code attached.
Interestingly, I once had the crash with the first error message in C locale:
# ./a.out
Connection timed out
Erreur de segmentation
#
Then again, I also had this once:
# ./a.out
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Erreur de segmentation
#
Could not reproduce under valgrind - still from gdb:
# gdb ./a.out
(...)
(gdb) run
(...)
Connexion terminée par
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x86bd0b90 (LWP 10614)]
0xb7e599d8 in strcmp () from /lib/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7e599d8 in strcmp () from /lib/i686/cmov/libc.so.6
#1 0xb7e0d473 in _nl_find_msg () from /lib/i686/cmov/libc.so.6
#2 0xb7e0e122 in __dcigettext () from /lib/i686/cmov/libc.so.6
#3 0xb7e0ceb3 in dcgettext () from /lib/i686/cmov/libc.so.6
#4 0xb7e59ee9 in strerror_r () from /lib/i686/cmov/libc.so.6
#5 0xb7e27c9f in vfprintf () from /lib/i686/cmov/libc.so.6
#6 0xb7e4a874 in vsnprintf () from /lib/i686/cmov/libc.so.6
#7 0xb7e2f1d5 in snprintf () from /lib/i686/cmov/libc.so.6
#8 0x080485f0 in run ()
#9 0xb7f3a4fb in start_thread () from /lib/i686/cmov/libpthread.so.0
#10 0xb7ebe60e in clone () from /lib/i686/cmov/libc.so.6
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (100, 'unstable'), (100, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.23.8 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6 depends on:
ii libgcc1 1:4.2.2-4 GCC support library
libc6 recommends no packages.
-- debconf information:
glibc/restart-failed:
glibc/restart-services:
--
Rémi Denis-Courmont
http://www.remlab.net/
#include stdio.h
#include pthread.h
#include locale.h
#include libintl.h
#include errno.h
#define NTH 100
static pthread_barrier_t *bp;
static void *run (void *dummy)
{
char buf[256];
(void)dummy;
errno = ETIMEDOUT;
pthread_barrier_wait (bp);
for (;;)
{
snprintf (buf, sizeof (buf), %m);
puts (buf);
}
}
int main (void)
{
unsigned i;
pthread_barrier_t barrier;
pthread_t threads[NTH];
setlocale (LC_ALL, );
bindtextdomain (vlc, /usr/share/locale);
pthread_barrier_init (barrier, NULL, NTH);
bp = barrier;
for (i = 0; i NTH; i++)
pthread_create (threads + i, NULL, run, NULL);
run (NULL);
return 0;
}
signature.asc
Description: This is a digitally signed message part.
Bug#456531: libc6: strerror_r() not thread-safe
Le Sunday 16 December 2007 17:55:18 Pierre Habouzit, vous avez écrit : like said, I'd like to have: * your libc6 version ; 2.7-4 * your libc6-i686 version ; 2.7-4 It also happens with libc6-i686 purged, in any case, so that's not that: #0 0xb7e31e21 in strcmp () from /lib/libc.so.6 #1 0xb7de5467 in _nl_find_msg () from /lib/libc.so.6 #2 0xb7de6102 in __dcigettext () from /lib/libc.so.6 #3 0xb7de4ea3 in dcgettext () from /lib/libc.so.6 #4 0xb7e32339 in strerror_r () from /lib/libc.so.6 #5 0xb7dffb44 in vfprintf () from /lib/libc.so.6 #6 0xb7e22bc4 in vsnprintf () from /lib/libc.so.6 #7 0xb7e07275 in snprintf () from /lib/libc.so.6 #8 0x080485f0 in run () #9 0xb7f12383 in start_thread () from /lib/libpthread.so.0 #10 0xb7e9663e in clone () from /lib/libc.so.6 * a valgrind trace, gdb is quite useless here. I have tried countless time to reproduce it under valgrind with no results. (...) at least give a bt full or whatever trace that gives line numbers. dcigettext is huge, I won't spot a bug just by reading it. I have libc6-dbg and that won't do it, what else am I supposed to do? -- Rémi Denis-Courmont http://www.remlab.net/ signature.asc Description: This is a digitally signed message part.
Bug#456531: libc6: strerror_r() not thread-safe
#1, #2 ==23149== New state: shared-modified by threads #1, #2 ==23149== Reason:this thread, #1, holds no consistent locks ==23149== Location 0x4F41BD8 has never been protected by any lock ==23149== ==23149== Possible data race during write of size 4 at 0x5741BD8 ==23149==at 0x402F548: pthread_join (pthread_join.c:102) ==23149==by 0x402583F: pthread_join (hg_intercepts.c:248) ==23149==by 0x80486D6: main (in /home/remi/a.out) ==23149== Old state: shared-readonly by threads #1, #3 ==23149== New state: shared-modified by threads #1, #3 ==23149== Reason:this thread, #1, holds no consistent locks ==23149== Location 0x5741BD8 has never been protected by any lock ==23149== ==23149== ERROR SUMMARY: 18 errors from 10 contexts (suppressed: 17 from 2) I have libc6-dbg and that won't do it, what else am I supposed to do? `bt full` instead of just `bt` doesn't shows line numbers ? I'm afraid it doesn't (even without libc6-i686). -- Rémi Denis-Courmont http://www.remlab.net/ signature.asc Description: This is a digitally signed message part.
Bug#443660: New test case for #443660
found 443660 2.7-4
thanks
Hello,
Seems like the original test case does not crash anymore. I still have
problems with this one new though - it crashes pseudorandomly (about 10%
crashes here). Unfortunately, I have not been able to reproduce the problem
under a debugger.
Interestingly, I once had the crash with the first error message in C locale:
# ./a.out
Connection timed out
Erreur de segmentation
#
Then again, I also had this once:
# ./a.out
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Connexion terminée par expiration du délai d'attente
Erreur de segmentation
#
--
Rémi Denis-Courmont
http://www.remlab.net/
#include stdio.h
#include pthread.h
#include locale.h
#include libintl.h
#include errno.h
#define NTH 100
static pthread_barrier_t *bp;
static void *run (void *dummy)
{
char buf[256];
(void)dummy;
errno = ETIMEDOUT;
pthread_barrier_wait (bp);
for (;;)
{
snprintf (buf, sizeof (buf), %m);
puts (buf);
}
}
int main (void)
{
unsigned i;
pthread_barrier_t barrier;
pthread_t threads[NTH];
setlocale (LC_ALL, );
bindtextdomain (vlc, /usr/share/locale);
pthread_barrier_init (barrier, NULL, NTH);
bp = barrier;
for (i = 0; i NTH; i++)
pthread_create (threads + i, NULL, run, NULL);
run (NULL);
return 0;
}
Bug#443660: #443660 still occurs
reopen 443660 found 443660 2.7-1 thanks I still have the exact same pseudo-reproducible crashes inside strerror_r with glibc 2.7-1 in unstable. Looks like VLC Linux port is going to not have localization anymore :( -- Rémi Denis-Courmont http://www.remlab.net/
Bug#443660: libc6: dgettext not thread-safe
Package: libc6
Version: 2.6.1-5
Severity: important
Tags: l10n
Hello,
Recent version of libc6 seems to include a libintl that regularly
crashes when gettext is invoked from different threads simultaneously.
This renders gettext mostly unusable on multi-threaded software.
I had been suspecting a bug in VLC and banging my head around, but it
appears that this can be reproduced with code as simple as the piece
above. It triggers a segmentation fault on a very time-dependant basis.
It seems a lot easier to reproduce under valgrind, though I also get
segfaults when run without debuggers:
#include stdio.h
#include pthread.h
#include locale.h
#include libintl.h
static void *run (void *dummy)
{
(void)dummy;
for (;;)
printf (Translation code: %s\n, dgettext(vlc, C));
}
int main (void)
{
unsigned i;
setlocale (LC_ALL, );
bindtextdomain (vlc, /usr/share/locale);
pthread_t threads[300];
for (i = 0; i sizeof (threads) / sizeof (threads[0]); i++)
pthread_create (threads + i, NULL, run, NULL);
run (NULL);
return 0;
}
When the problem occurs under valgrind, it complains:
==3535== Thread 3:
==3535== Invalid read of size 4
==3535==at 0x4063F0B: _nl_find_msg (dcigettext.c:862)
==3535==by 0x4064A41: __dcigettext (dcigettext.c:639)
==3535==by 0x4063972: dcgettext (dcgettext.c:53)
==3535==by 0x406399F: dgettext (dgettext.c:54)
==3535==by 0x80484DD: run (in /home/remi/a.out)
==3535==by 0x402D2D2: start_thread (pthread_create.c:296)
==3535==by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)
==3535== Address 0x418C91C is 0 bytes after a block of size 12 alloc'd
==3535==at 0x4024862: realloc (vg_replace_malloc.c:306)
==3535==by 0x4063FF1: _nl_find_msg (dcigettext.c:876)
==3535==by 0x4064A41: __dcigettext (dcigettext.c:639)
==3535==by 0x4063972: dcgettext (dcgettext.c:53)
==3535==by 0x406399F: dgettext (dgettext.c:54)
==3535==by 0x80484DD: run (in /home/remi/a.out)
==3535==by 0x402D2D2: start_thread (pthread_create.c:296)
==3535==by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)
There appears to be a similar issue with strerror_r() also.
Regards,
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (100, 'unstable'), (100, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.20.15 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libc6 depends on:
ii libgcc1 1:4.2.1-5 GCC support library
libc6 recommends no packages.
-- debconf information:
glibc/restart-failed:
glibc/restart-services:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443660: libc6: dgettext not thread-safe
Le Sunday 23 September 2007 12:15:31 Pierre Habouzit, vous avez écrit :
On Sun, Sep 23, 2007 at 08:15:45AM +, Rémi Denis-Courmont wrote:
#include stdio.h
#include pthread.h
#include locale.h
#include libintl.h
static void *run (void *dummy)
{
(void)dummy;
for (;;)
printf (Translation code: %s\n, dgettext(vlc, C));
}
int main (void)
{
unsigned i;
setlocale (LC_ALL, );
bindtextdomain (vlc, /usr/share/locale);
pthread_t threads[300];
for (i = 0; i sizeof (threads) / sizeof (threads[0]); i++)
pthread_create (threads + i, NULL, run, NULL);
run (NULL);
return 0;
}
When the problem occurs under valgrind, it complains:
==3535== Thread 3:
==3535== Invalid read of size 4
This is probably because of a speculative strcmp (libc sometimes reads
outside the string because it knows it can).
==3535==at 0x4063F0B: _nl_find_msg (dcigettext.c:862)
==3535==by 0x4064A41: __dcigettext (dcigettext.c:639)
==3535==by 0x4063972: dcgettext (dcgettext.c:53)
==3535==by 0x406399F: dgettext (dgettext.c:54)
==3535==by 0x80484DD: run (in /home/remi/a.out)
==3535==by 0x402D2D2: start_thread (pthread_create.c:296)
==3535==by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)
==3535== Address 0x418C91C is 0 bytes after a block of size 12 alloc'd
==3535==at 0x4024862: realloc (vg_replace_malloc.c:306)
==3535==by 0x4063FF1: _nl_find_msg (dcigettext.c:876)
==3535==by 0x4064A41: __dcigettext (dcigettext.c:639)
==3535==by 0x4063972: dcgettext (dcgettext.c:53)
==3535==by 0x406399F: dgettext (dgettext.c:54)
==3535==by 0x80484DD: run (in /home/remi/a.out)
==3535==by 0x402D2D2: start_thread (pthread_create.c:296)
==3535==by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)
This one though looks fishy.
It's the same error! It only means that _nl_find_msg from dcigettext.c:862
tries to read at an address right after the end of a realloc() done at line
876 in the same file, as far as I understand.
After the above errors, I usually get this:
==29015== Invalid read of size 1
==29015==at 0x40255DE: strcmp (mc_replace_strmem.c:341)
==29015==by 0x4063F18: _nl_find_msg (dcigettext.c:862)
==29015==by 0x4064A41: __dcigettext (dcigettext.c:639)
==29015==by 0x4063972: dcgettext (dcgettext.c:53)
==29015==by 0x406399F: dgettext (dgettext.c:54)
==29015==by 0x80484DD: run (in /home/remi/a.out)
==29015==by 0x402D2D2: start_thread (pthread_create.c:296)
==29015==by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)
==29015== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==29015==
==29015== Process terminating with default action of signal 11 (SIGSEGV)
==29015== Access not within mapped region at address 0x0
==29015==at 0x40255DE: strcmp (mc_replace_strmem.c:341)
==29015==by 0x4063F18: _nl_find_msg (dcigettext.c:862)
==29015==by 0x4064A41: __dcigettext (dcigettext.c:639)
==29015==by 0x4063972: dcgettext (dcgettext.c:53)
==29015==by 0x406399F: dgettext (dgettext.c:54)
==29015==by 0x80484DD: run (in /home/remi/a.out)
==29015==by 0x402D2D2: start_thread (pthread_create.c:296)
==29015==by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)
Looks like strcmp tries to compare with NULL.
--
Rémi Denis-Courmont
http://www.remlab.net/
Bug#404379: Please provide a default /etc/gai.conf
package: libc6 severity: wishlist version: 2.5-0exp3 Tags: experimental Libc6 2.5 and up implements configurable source address selection policy through /etc/gai.conf, yet the file is not shipped, there is no documentation and the template from upstream is not even in /usr/share/doc/libc6/whatever. Regards, -- Rémi Denis-Courmont http://www.remlab.net/ pgpNeQeZD5hPj.pgp Description: PGP signature
