Re: deadlock in signal handler with NPTL

[Steve Munroe <sjmunroe at us dot ibm dot com>]

Thorsten Kukuk <kukuk@suse.de> wrote on 06/22/2004 11:22:56 PM:

> On Tue, Jun 22, Jakub Jelinek wrote:
>
> > 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.
>
> Yes, but the problem is: Nearly every daemon on a Linux system is
> calling syslog() in a signal handler and it seems to be very easy
> to deadlock them on every Linux system running glibc/NPTL. While
> there seems to be no other system with the same problem.
>

Then what has change from glibc-2.3.3 (RHEL 3) until now? Because I have
not seen this problem before. I have reviewed all the changes to
lowlevellock.h since and I do not see any change that would effect this. In
fact your test case should show that same hang there.

Have the daemon's changed recently to add the syslog() call to the signal
handler?

Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center