On Wed, Oct 21, 2009 at 10:40:03PM +0300, Rémi Denis-Courmont wrote: > 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... >
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? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
