[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: deadlock in NPTL, FUTEX
From: |
Paul Pluzhnikov |
Subject: |
Re: deadlock in NPTL, FUTEX |
Date: |
Tue, 23 Sep 2008 22:05:44 -0700 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) |
Bernhard Ibertsberger <elgringo@gmx.at> writes:
>> This isn't new to NPTL; you could have encountered the exact same
>> deadlock with LinuxThreads.
>
> Yes, you are right. But running [1] and [2] like
> LD_ASSUME_KERNEL=2.4.1: ./ctime-hang
> does not show a deadlock.
On your machine, for the limited number of tries.
ctime-hang *does* deadlock on my machine every time, using either
NPTL or LinuxThreads.
> Why does it behave like that?
When you perform operation, results of which are undefined, any
outcome is possible, including apparently correct execution.
> It was your demo and the hint to the term "async-signal safe", that
> gave me a good insight!
> Though it does not explain why the deadlock depends on the kernel version.
LD_ASSUME_KERNEL does *not* change kernel version (you need a reboot
for that). What it may do is select a different version of glibc,
with different timing and different code layout, and these differences
may allow the bug to hide better.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.