This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: deadlock in signal handler with NPTL

From: Jakub Jelinek <jakub at redhat dot com>
To: Thorsten Kukuk <kukuk at suse dot de>
Cc: libc-hacker at sources dot redhat dot com
Date: Tue, 22 Jun 2004 21:52:37 +0200
Subject: Re: deadlock in signal handler with NPTL
References: <20040622215059.GA1204@suse.de>
Reply-to: Jakub Jelinek <jakub at redhat dot com>

On Tue, Jun 22, 2004 at 11:50:59PM +0200, Thorsten Kukuk wrote:
> 
> Hi,
> 
> I got the following test program. I know, it is very ugly and there
> are a lot of things somebody should not do, but this is something
> what programs like sshd are doing.

Then they should be fixed.  Neither syslog, nor printf, nor fflush
are supposed to be async-signal safe, nor they actually are in glibc.

> The problem is: This program deadlocks very fast in a FUTEX_WAIT
> call. This does not happen with LinuxThreads.

Try linking the program with -lpthread and retry with LinuxThreads.
It will hang the same way.
The thing is that NPTL uses locking (on IA-32/x86-64 without lock prefix)
even when -lpthread has not been linked in.

	Jakub

Follow-Ups:
- Re: deadlock in signal handler with NPTL
  - From: Thorsten Kukuk

References:
- deadlock in signal handler with NPTL
  - From: Thorsten Kukuk

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]