Bug#551903: libc6-i686 pthread_cond_wait fails to reacquire mutex upon cancellation
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
aurelien@aurel32.net http://www.aurel32.net
Reply to: