Bug 171513 - static linked program using pthread segfault executing pthread_mutex_init
static linked program using pthread segfault executing pthread_mutex_init
Status: CLOSED DUPLICATE of bug 115157
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-21 18:42 EDT by Gene Czarcinski
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-23 03:06:39 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)

  None (edit)
Description Gene Czarcinski 2005-10-21 18:42:47 EDT
Description of problem:

I really dislike filing this report because I feel that the problem is not with
glibc but ... that is the only place I can find.

The program involved is "partimage" and it very large.

The system is FC4 with current maintenance ... specifically glibc-2.3.5-10.3

As I use partimage, the executable is created in both with dynamically linked
and completely statically linked versions.

partimage uses pthreads to create an extra thread to write debugging info to a
file (it uses pthreads in other places but they are not invoked as I use the
program).

When I run the dynamically linked executable, everything works OK.

When I run the statically linked executable, I get a segmentation fault which I
have narrowed down to the execution of pthread_mutex_init(...)

I have a coredump with the problem (repeatable, can create on demand).

I have tried running the program with gdb but I get:

Starting program: /home/devel/rpmbuild/BUILD/partimage-0.6/src/client/partimage
Reading symbols from shared object read from target memory...done.
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error
Cannot find user-level thread for LWP 8827: generic error

If this is another bug I will report it separately.

Any hints as to the problem would be greatly appreciated.

Any hints as to how to get more info would also be appreciated.

BTW, this worked fine with FC3 and the "old" threads code.

I have also used the thread examples from glibc and statically linked them but
they work fine.
Comment 1 Gene Czarcinski 2005-10-22 10:00:59 EDT
OK, I have finally determined that the function call to pthread_mutex_init() is
not being resolved (it is "call 0x0" in the ddd disassembly) ... yes, I figured
out how to get gdb/ddd to work inspite of the "error" ... simply continue.

Here is the static link command as original:

g++ -Wall -g -O2 -o partimage -static netclient.o imagefile.o misc.o image_net.o
buffer.o gui_text.o main.o imginfo.o cbitmap.o interface_base.o interface_newt.o
interface_none.o mbr_backup.o  -L/usr/local/lib -lslang fs/libfs.a
../shared/libshared.a -lz -lnewt -lbz2 -lpthread /usr/lib/libslang.a
/usr/lib/libnewt.a /usr/lib/libdl.a /usr/lib/libpthread.a

did not work.  I then tried this:

g++ -Wall -g -O2 -o partimage -static netclient.o imagefile.o misc.o image_net.o
buffer.o gui_text.o main.o imginfo.o cbitmap.o interface_base.o interface_newt.o
interface_none.o mbr_backup.o  -L/usr/local/lib -lslang fs/libfs.a
../shared/libshared.a -lz -lnewt -lbz2  /usr/lib/libslang.a /usr/lib/libnewt.a
/usr/lib/libdl.a /usr/lib/libpthread.a /usr/lib/libpthread_nonshared.a

again, it did not work.  I then built )compiled) the glibc from the src.rpm and
copied glibc-20050524T1606/build-i486-linuxnptl/nptl/pthread_mutex_init.o to the
directory with my progam and did this:

g++ -Wall -g -O2 -o partimage -static netclient.o imagefile.o misc.o image_net.o
buffer.o gui_text.o main.o imginfo.o cbitmap.o interface_base.o interface_newt.o
interface_none.o mbr_backup.o  pthread_mutex_init.o   -L/usr/local/lib -lslang
fs/libfs.a ../shared/libshared.a -lz -lnewt -lbz2  /usr/lib/libslang.a
/usr/lib/libnewt.a /usr/lib/libdl.a /usr/lib/libpthread.a
/usr/lib/libpthread_nonshared.a

This worked!  The program executed with (apparently) the other ptheread function
calls being resolved.  Stepping through the programs execution with ddd, this
time the call I saw was resolved to "call pthread_mutex_init" rather tha "call 0x0"

Now this may have worked but it is not a fix.

Any hints as to what I am doing wrong?
Comment 2 Gene Czarcinski 2005-10-22 12:17:58 EDT
OK, as an additional test, I hacked up the Makefiles to use
/usr/include/linuxthreads headers and /usr/lib/linuxthreads libraries.

This works with no problems.
Comment 3 Gene Czarcinski 2005-10-22 13:46:18 EDT
Mmmm ... this does appear to be a dup of
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115157
Comment 4 Gene Czarcinski 2005-10-22 16:28:16 EDT
Since everything seems to work OK using (the old) linuxthreads and it has
"#pragma weak" also specified, why does this work and the ntpl does not?
Comment 5 Jakub Jelinek 2005-10-23 03:06:39 EDT

*** This bug has been marked as a duplicate of 115157 ***
Comment 6 Gene Czarcinski 2005-10-23 17:24:46 EDT
After spending lots of time (about three days) trying to figure out what the
pthread (segfault) problem was [it took a while until I understood that the
function call had not been resolved when it was statically linked], I find that
it was a waste of time [well, I did learn a bit about "weak" linkage].

As I said above, the problem was with statically linked partimage which was
statically linked so that I did not need to worry about extra libraries when I
ran it under the rescuecd.

Well, I need not have worried, the shared linked version runs just fine under
the rescuecd ... all the needed libraries (newt, slang, bz2, z, AND pthread)
where there.

At least not I do not have to wait for Alexandre's fix to work its way into
production.

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