Bug 20482 - Differences between static and dynamic ptherad libraries
Differences between static and dynamic ptherad libraries
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-07 13:52 EST by Need Real Name
Modified: 2016-11-24 10:23 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.3.2-27.9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-21 21:21:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a simple multithreaded program with mutexes (1.25 KB, text/plain)
2000-11-07 17:49 EST, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2000-11-07 13:52:27 EST
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
Comment 1 Jakub Jelinek 2000-11-07 16:45:06 EST
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?
Comment 2 Need Real Name 2000-11-07 17:49:03 EST
Created attachment 5140 [details]
a simple multithreaded program with mutexes
Comment 3 Need Real Name 2000-11-07 17:55:10 EST
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.


Comment 4 Need Real Name 2000-11-07 18:35:47 EST
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
Comment 5 Jakub Jelinek 2000-11-08 08:46:05 EST
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.
Comment 6 Need Real Name 2000-11-08 13:11:34 EST
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.
Comment 7 Need Real Name 2000-11-08 13:21:40 EST
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.
Comment 8 Jakub Jelinek 2000-11-08 16:28:08 EST

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.
Comment 9 William Brower 2001-08-18 18:36:57 EDT
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!

Comment 10 Jakub Jelinek 2001-08-19 07:10:55 EDT
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
Comment 11 Ulrich Drepper 2003-04-21 21:21:45 EDT
I cannot reproduce any problem.  Your test case works fine on a RHL9 system.  If
you still have problems please open a new bug.

Note You need to log in before you can comment on or make changes to this bug.