Bug#551903: libc6-i686 pthread_cond_wait fails to reacquire mutex upon cancellation
On Fri, Jun 04, 2010 at 11:25:28AM +0200, Aurelien Jarno wrote:
> Aurelien Jarno a écrit :
> > On Thu, Jun 03, 2010 at 10:09:45PM +0300, Rémi Denis-Courmont wrote:
> >> 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 200000 times over last
> >>> night.
> >> With SMT ("HyperThread") support?
> >
> > Yes, with HyperThreading enabled.
> >
> >>> 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.
> >>
> >
> > I tried on a 2.6.26 kernel, I'll try to reproduce it with this kernel.
> >
>
> I tried on a 2.6.32-5-686 kernel, and it hasn't failed in more than
> 300000 loops. There is probably something different on your system
> causing the issue.
>
I have modified a bit the testcase so that it runs in a loop, and I
removed all timing functions (see attached file). I am able to reproduce
the problem in some conditions:
- It fails between 200000 and 3 millions of iterations on
dual-core i386 CPU in lenny, squeeze and sid.
- It never fails on HT CPU (tried P4 and Atom)
- It never fails when pinned on a single CPU using taskset
- It never fails on amd64
- It fails in lenny, testing and unstable
- It seems to fail more quickly in a KVM instance (probably more
timing variation).
This seems to confirm there is a race condition, but very difficult to
reproduce. My guess is that a P4 CPU running at 2.8 GHz with HT enabled
has the perfect timing to reproduce the bug.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: