I've noticed a difference between the static and dynamic versions of the pthread library. It appears that the statically linked version behaves normally. The dynamically linked version stops executing the application when two threads are waiting to lock the same mutex. Execution never resumes to the thread that has the mutex locked. The only difference between the two during the make is using the - static linker option. The dynamic version of the program is linked to these libraries: libldap.so.1 => /usr/lib/libldap.so.1 (0x40023000) liblber.so.1 => /usr/lib/liblber.so.1 (0x40039000) libpthread.so.0 => /lib/libpthread.so.0 (0x4003f000) libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40055000) libm.so.6 => /lib/libm.so.6 (0x40098000) libc.so.6 => /lib/libc.so.6 (0x400b8000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Another problem that I noticed between the dynamic and static versions is that gdb will report many warnings when I try to debug the static version: GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"...rw_common (): write: Function not implemented. warning: unable to set global thread event mask [New Thread 1024 (active)] rw_common (): write: Function not implemented. warning: stop_or_attach_thread: generic error And consequently debugging multithreaded apps is nearly impossible, since the debugger can no longer switch between threads or even list them with "info threads". I do not get these messages with the dynamically linked version of my binary. I've since upgraded the glibc libraries from the 7.0 support/upgrade pages hoping that they would fix my problem. Here is rpm -qa | grep glibc output: glibc-devel-2.1.94-3 glibc-2.1.94-3 Intially this was a RH 6.2 box and there were no differences between a statically or dynamically linked binary (executing behavior that is). I upgraded using the 2 cds out of the 7.0 box with the upgrade procedure. Initially, 6.2 was installed using custom/install everything. I recently rpm -e compat* packages to ensure that they were not causing my problems; no change. I checked my source out of cvs on another RH box, a 6.0 one, and the binaries work the same statically or dynamically linked. Also gdb functions correctly with both binaries. The same source also compiles and runs correctly on several other unixes including solaris 2.7, and MacOS X. All binaries are built using the -g gcc/g++ option. I've verified my gcc/glibc packages with -V. This problem is definitely new with 7.0. Mike Harris Software Engineer FileMaker, Inc. 408-987-7504
By any change, aren't the threads locking in endl or ends C++ iostream functions? That was a bug in libstdc++ which has been fixed already. If not, can you either put up a testcase where it locks up when dynamically linked or give me access to your program including instructions how to reproduce it?
Created attachment 5140 [details] a simple multithreaded program with mutexes
build commands: g++ -g -static -o testmutex_static testmutex.cpp -lpthread g++ -g -o testmutex testmutex.cpp -lpthread Your right, looks like it is endl causing the problems only in a dynamically linked binary! Execution stops after Thread C prints it output in the dynamically linked version. However, the gdb issues are visible in the statically linked binary. In gdb: (gdb) break threadB (gdb) run The current thread is the wrong one, and there is no list of threads (info threads). So you cannot switch to the right one.
In the interest of completeness... I made another simple single threaded app that used endl. No problems either dynamically or statically linked. Also no problems with gdb. This app did not include the pthread library, which would be the only difference. Mike
Please try libstdc++*2.96-6[0-3].*.rpm in rawhide (dunno which release is there currently), it should be fixed in there. AFAIK gdb support for threads is for dynamically linked apps only.
What is the path for this rpm on the ftp server? I've checked updates/7.0/ ix86/, and nothing. Also, current/i386/RedHat/RPMS has the same one I have, 2.96-54.
I'm unaware of any limitations of gdb on statically linked binaries, as I've been using gdb on statically linked binaries in the past (including on RH 6.2). It's only recently started having problems as of RH 7.0.
The rpms are in rawhide currently, which is ftp.redhat.com/rawhide/i386/ As far as debugging statically linked threaded programs goes, you're right that it somehow (although pretty badly) worked in 6.2, but the code for handling threads is completely new in gdb 5.x. If you confirm that the first bug is fixed by libstdc++ from rawhide, I'll reassign this bug to gdb.
I'm using RH7.1 (kernel 2.4.2-2) and find gdb (--version: GNU gdb 5.0rh-5 Red Hat Linux 7.1) can't debug any multi-threaded apps because the pthreads library was shipped as stripped: file /lib/libpthread-0.9.so /lib/libpthread-0.9.so: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped Mandrake 7.x (?) has this same problem. Don't strip these libraries!
Unless you have LD_ASSUME_KERNEL=2.2.5 set in environment or unless you actually run kernel earlier than 2.4.1, this library is not used (and as this is not the common case, I think it is much better to have this stripped than not stripped): file /lib/libpthread-0.9.so /lib/i686/libpthread-0.9.so /lib/libpthread-0.9.so: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped /lib/i686/libpthread-0.9.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped
I cannot reproduce any problem. Your test case works fine on a RHL9 system. If you still have problems please open a new bug.