This is the mail archive of the mailing list for the glibc project.

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

[] libc/1305: Strange rt_sigsuspend problem with pthreads

The appended bug report shows a problem that in 2.1.2 and also in the
actual development versions of 2.1.3 and 2.2 (Ulrich's recent patches
to linuxthreads didn't help).  The simple program hangs if it has been
linked against libpthread.a

Here's a stacktrace from gdb:

Program received signal SIGINT, Interrupt.
0x4003b205 in __sigsuspend (set=0xbffff558)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
(gdb) bt
#0  0x4003b205 in __sigsuspend (set=0xbffff558)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
#1  0x804d5e0 in __pthread_lock (lock=0x400f8a20, self=0x8053440)
    at restart.h:32
#2  0x804d9fe in __pthread_mutex_lock (mutex=0x400f8a10) at mutex.c:84
#3  0x4003d75e in __new_exitfn () at atexit.c:51
#4  0x4003d6bb in __on_exit (func=0x804c2b0 <pthread_exit_process>, arg=0x0)
    at on_exit.c:26
#5  0x804bd8f in pthread_initialize () at pthread.c:346
#6  0x804bda7 in __pthread_initialize () at pthread.c:351
#7  0x4006c194 in ptmalloc_init () at malloc.c:1672
#8  0x4006c38f in malloc_hook_ini (sz=392, caller=0x4003d7b1) at malloc.c:1724
#9  0x4006c9ae in __libc_malloc (bytes=392) at malloc.c:2630
#10 0x4003d7b1 in __new_exitfn () at atexit.c:70
#11 0x4003d70b in atexit (func=0x40009ac4 <_dl_fini>) at atexit.c:28
#12 0x40035205 in __libc_start_main (main=0x8049ff0 <main>, argc=1, 
    argv=0xbffff8c4, init=0x8049aec <_init>, fini=0x804e388 <_fini>, 
    rtld_fini=0x40009ac4 <_dl_fini>, stack_end=0xbffff8bc)
    at ../sysdeps/generic/libc-start.c:64

Anybody with a solution for this problem?


>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
>Originator:     Robin Verduijn
>Release:        libc-2.1.2
Host type: i586-mandrake-linux-gnu
System: Linux 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:

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

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.

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...

None that I know of. Or perhaps:
    1) Don't link with pthread, or
	2) don't use write()

It's weird.....

 Andreas Jaeger
  for pgp-key finger

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