Re: deadlock in NPTL, FUTEX

[Paul Pluzhnikov]

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.