- To: bugs at gnu dot org
- Subject: libc/1305: Strange rt_sigsuspend problem with pthreads
- From: robin at warande dot net
- Date: 18 Sep 1999 18:30:56 -0000
- Xref: gromit.rhein-neckar.de mail.gnats-libc-bugs:3827
>Number: 1305
>Category: libc
>Synopsis: programs hang in rt_sigsuspend before any threads have been created
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: libc-gnats
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Sat Sep 18 12:40:02 EDT 1999
>Last-Modified:
>Originator: Robin Verduijn
>Organization:
>Release: libc-2.1.2
>Environment:
Host type: i586-mandrake-linux-gnu
System: Linux empire.warande.net 2.2.13-7mdk #1 Sat Sep 18 11:51:59 CEST 1999 i586 unknown
Architecture: i586
Addons: crypt glibc-compat linuxthreads
Build CFLAGS: -O6 -fomit-frame-pointer -fno-exceptions -fno-rtti -pipe -s -mpentium -mcpu=pentium -march=pentium -ffast-math -fexpensive-optimizations -O6 -fstrict-aliasing
Build CC: gcc
Compiler version: pgcc-2.91.66 19990314 (egcs-1.1.2 release)
Kernel headers: 2.2.13-7mdk
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: no
Build profile: yes
Build omitfp: no
Build bounded: no
Build static-nss: no
Stdio: libio
Installed (relevant) packages:
gcc-2.95.1-1mdk
gcc-cpp-2.95.1-1mdk
glibc-2.1.2-1mdk
glibc-devel-2.1.2-1mdk
kernel-2.2.13-7mdk
>Description:
I have been having a strange problem lately, which may have
something to do with the pthreads library. Basically, what happens
is that a program which has been linked with the pthread library
"hangs" on startup in what seems to be a call of rt_sigsuspend. The
last lines of a typical trace would be like this:
rt_sigaction(SIGRT_0, {0x804bc8f, [], 0}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x804b603, [], 0}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0x804bd07, [], 0}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RT_0], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
rt_sigsuspend([]
I've already contacted mr. Xavier Leroy about this and he said the following
about it:
"I'm puzzled by this trace. The first four lines are the normal
LinuxThreads initialization sequence, so it's OK. The last two lines
match what LinuxThreads does when a thread needs to be put to sleep,
waiting for some event (e.g. waiting for another thread to release a
lock). However, since your program hasn't created any threads yet, it
should never have to wait for ay event from another thread!
One possible cause for this would be a mutex that is not properly
initialized in the C runtime library: the first time the program locks
this mutex, it thinks that the mutex is already taken and suspends
until "someone else" unlocks it.
This is just an example -- there are other possible causes with
similar effects. Still, my feeling is that the problem could be
related to the C library."
He also advised me to file a bug report with you guys.
I got this problem with several applications I compiled (licq 0.7x and
Mozilla M9) but since it happens even with all of the programs in the glibc
example.threads directory I figured it had to have something to do with the
thread library.
The problem also appears when I only link in the pthread library, without
making any pthread function calls.
>How-To-Repeat:
Compile the following program and link it with /usr/lib/libpthread.a:
#include <unistd.h>
void essential( void )
{
write(0, (char *) NULL, 0);
}
void main( void ) {}
I compiled it like this:
gcc -g -O -Wall -D_REENTRANT -o hang hang.c /usr/lib/libpthread.a
If you do not link with the libpthread library, the hang doesn't occur.
Also, if I omit the write() call I don't get any problems either.
Note that that write() should never really be called. Why it does have
any effect is beyond me...
>Fix:
None that I know of. Or perhaps:
1) Don't link with pthread, or
2) don't use write()
It's weird.....
>Audit-Trail:
>Unformatted: