From: Andrew Lofthouse <loftyhauser@gmail.com>
To: gdb@sourceware.org
Subject: Re: "Cannot find new threads" on Fedora 9, but not on CentOS 5 (?)
Date: Wed, 29 Oct 2008 01:16:00 -0000 [thread overview]
Message-ID: <4907B915.5040101@gmail.com> (raw)
In-Reply-To: <8ac60eac0810271836saf8c28pb1392b77c7926be0@mail.gmail.com>
Sorry for the delay; I don't have access to my personal e-mail account
at work...
Paul Pluzhnikov wrote:
> - What does 'ldd /path/to/app' say?
> - What does 'nm /path/to/libpthread.so.0 | grep _version' say (where
> /path/to/libpthread.so.0 is the one which ldd prints)?
Hmm, ldd does not list libpthread.so.0:
[andrew@fedora-vm ufs]$ ldd /usr/local/bin/ufs2oogl2D
linux-gate.so.1 => (0x0012e000)
libufs2D-0.9.so.2 => /usr/local/lib/libufs2D-0.9.so.2 (0x0012f000)
libgts-0.7.so.5 => /usr/local/lib/libgts-0.7.so.5 (0x001d8000)
libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x00228000)
libdl.so.2 => /lib/libdl.so.2 (0x0022c000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00231000)
libm.so.6 => /lib/libm.so.6 (0x00312000)
libc.so.6 => /lib/libc.so.6 (0x0033b000)
libselinux.so.1 => /lib/libselinux.so.1 (0x004a4000)
/lib/ld-linux.so.2 (0x00110000)
But, gdb still seems to use libpthread when debugging the application
(see below).
>
>>> This is most likely result of "pilot error" (stripping
>>> libpthread.so.0, or incomplete installation of glibc), and has
>>> nothing to do with actual version of GDB.
>> Except that libpthread.so.0 is not stripped (on any of the installations).
>
> How do you know that?
Now I'm confused. It looks like the non-debug library is not stripped,
but the debug library is stripped (?):
[andrew@fedora-vm ufs]$ file /lib/libpthread-2.8.so
/lib/libpthread-2.8.so: ELF 32-bit LSB shared object, Intel 80386,
version 1 (SYSV), for GNU/Linux 2.6.9, not stripped
[andrew@fedora-vm ufs]$ file /usr/lib/debug/lib/libpthread-2.8.so.debug
/usr/lib/debug/lib/libpthread-2.8.so.debug: ELF 32-bit LSB shared
object, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, stripped
Now, looking in gdb, it looks like gdb is using /lib/libpthread.so.0,
but can't find its symbols:
[andrew@fedora-vm ufs]$ gdb /usr/local/bin/ufs2oogl2D
GNU gdb Fedora (6.8-1.fc9)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) run -T "rho" < UAM10_002_UFS-005000.sim > test.plt
Starting program: /usr/local/bin/ufs2oogl2D -T "rho" <
UAM10_002_UFS-005000.sim > test.plt
Detaching after fork from child process 8745.
[Thread debugging using libthread_db enabled]
Error while reading shared library symbols:
Cannot find new threads: generic error
Cannot find new threads: generic error
(gdb) info share
From To Syms Read Shared Object Library
0x00110810 0x0012724f Yes /lib/ld-linux.so.2
0x0013ef00 0x001ca5d8 Yes /usr/local/lib/libufs2D-0.9.so.2
0x001dfb80 0x00221638 Yes /usr/local/lib/libgts-0.7.so.5
0x00228c50 0x00229cc8 Yes /lib/libgmodule-2.0.so.0
0x0022ca60 0x0022da68 Yes /lib/libdl.so.2
0x002401f0 0x002bf4d8 Yes /lib/libglib-2.0.so.0
0x00315420 0x0032fe48 Yes /lib/libm.so.6
0x003513b0 0x0045dc88 Yes /lib/libc.so.6
0x004a7bb0 0x004b7ce8 Yes /lib/libselinux.so.1
0x004c0430 0x004c05a8 Yes /tmp/gfsZ54KNU
0x004c2f50 0x004c4748 Yes /lib/libgthread-2.0.so.0
0x004c8940 0x004cd088 Yes /lib/librt.so.1
0x004d51f0 0x004e0b58 No /lib/libpthread.so.0
(gdb) share
Symbols already loaded for /lib/ld-linux.so.2
Symbols already loaded for /usr/local/lib/libufs2D-0.9.so.2
Symbols already loaded for /usr/local/lib/libgts-0.7.so.5
Symbols already loaded for /lib/libgmodule-2.0.so.0
Symbols already loaded for /lib/libdl.so.2
Symbols already loaded for /lib/libglib-2.0.so.0
Symbols already loaded for /lib/libm.so.6
Symbols already loaded for /lib/libc.so.6
Symbols already loaded for /lib/libselinux.so.1
Symbols already loaded for /tmp/gfsZ54KNU
Symbols already loaded for /lib/libgthread-2.0.so.0
Symbols already loaded for /lib/librt.so.1
Loaded symbols for /lib/libpthread.so.0
(gdb) info share
From To Syms Read Shared Object Library
0x00110810 0x0012724f Yes /lib/ld-linux.so.2
0x0013ef00 0x001ca5d8 Yes /usr/local/lib/libufs2D-0.9.so.2
0x001dfb80 0x00221638 Yes /usr/local/lib/libgts-0.7.so.5
0x00228c50 0x00229cc8 Yes /lib/libgmodule-2.0.so.0
0x0022ca60 0x0022da68 Yes /lib/libdl.so.2
0x002401f0 0x002bf4d8 Yes /lib/libglib-2.0.so.0
0x00315420 0x0032fe48 Yes /lib/libm.so.6
0x003513b0 0x0045dc88 Yes /lib/libc.so.6
0x004a7bb0 0x004b7ce8 Yes /lib/libselinux.so.1
0x004c0430 0x004c05a8 Yes /tmp/gfsZ54KNU
0x004c2f50 0x004c4748 Yes /lib/libgthread-2.0.so.0
0x004c8940 0x004cd088 Yes /lib/librt.so.1
0x004d51f0 0x004e0b58 Yes /lib/libpthread.so.0
(gdb) run -T "rho" < UAM10_002_UFS-005000.sim > test.plt
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/bin/ufs2oogl2D -T "rho" <
UAM10_002_UFS-005000.sim > test.plt
Detaching after fork from child process 8775.
[Thread debugging using libthread_db enabled]
Error while reading shared library symbols:
Cannot find new threads: generic error
Cannot find new threads: generic error
(gdb) info share
From To Syms Read Shared Object Library
0x00110810 0x0012724f Yes /lib/ld-linux.so.2
0x0013ef00 0x001ca5d8 Yes /usr/local/lib/libufs2D-0.9.so.2
0x001dfb80 0x00221638 Yes /usr/local/lib/libgts-0.7.so.5
0x00228c50 0x00229cc8 Yes /lib/libgmodule-2.0.so.0
0x0022ca60 0x0022da68 Yes /lib/libdl.so.2
0x002401f0 0x002bf4d8 Yes /lib/libglib-2.0.so.0
0x00315420 0x0032fe48 Yes /lib/libm.so.6
0x003513b0 0x0045dc88 Yes /lib/libc.so.6
0x004a7bb0 0x004b7ce8 Yes /lib/libselinux.so.1
0x004c0430 0x004c05a8 Yes /tmp/gfsZ54KNU
0x004c2f50 0x004c4748 Yes /lib/libgthread-2.0.so.0
0x004c8940 0x004cd088 Yes /lib/librt.so.1
0x004d51f0 0x004e0b58 No /lib/libpthread.so.0
Following your example:
> I have a fresh out-of-the-box installation of Fedora 9 for x86_64.
> Here is what I see:
>
> $ cat t.c
> #include <pthread.h>
>
> void *fn(void *p)
> {
> char *cp = (char *)p;
> cp[0] = 'a';
> return p;
> }
>
> int main()
> {
> pthread_t tid;
> pthread_create(&tid, 0, fn, 0);
> pthread_join(tid, 0);
> return 0;
> }
>
> $ gcc -g -pthread t.c && gdb ./a.out
> GNU gdb Fedora (6.8-1.fc9)
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu"...
> (gdb) run
> Starting program: a.out
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7ff617b6c6f0 (LWP 2907)]
> [New Thread 0x42533950 (LWP 2910)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x42533950 (LWP 2910)]
> 0x0000000000400590 in fn (p=0x0) at t.c:6
> 6 cp[0] = 'a';
> Missing separate debuginfos, use: debuginfo-install glibc.x86_64
> (gdb) info thread
> * 2 Thread 0x42533950 (LWP 2910) 0x0000000000400590 in fn (p=0x0) at t.c:6
> 1 Thread 0x7ff617b6c6f0 (LWP 2907) 0x0000003c9f807b75 in
> pthread_join () from /lib64/libpthread.so.0
> (gdb) quit
> The program is running. Exit anyway? (y or n) y
>
> $ rpm -qf /lib64/libpthread.so.0 /lib64/libthread_db.so.1
> glibc-2.8-3.x86_64
> glibc-2.8-3.x86_64
>
> I did 'debuginfo-install glibc.x86_64' just to check if that makes
> any difference... It didn't:
>
> (gdb) run
> Starting program: /root/a.out
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7f7e9e9ce6f0 (LWP 2948)]
> [New Thread 0x426f2950 (LWP 2951)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x426f2950 (LWP 2951)]
> 0x0000000000400590 in fn (p=0x0) at t.c:6
> 6 cp[0] = 'a';
> (gdb) inf thread
> * 2 Thread 0x426f2950 (LWP 2951) 0x0000000000400590 in fn (p=0x0) at t.c:6
> 1 Thread 0x7f7e9e9ce6f0 (LWP 2948) 0x0000003c9f807b75 in
> pthread_join (threadid=<value optimized out>,
> thread_return=<value optimized out>) at pthread_join.c:89
> (gdb)
>
I get essentially the same output.
It looks like something to do with gdb not finding the symbols for
/lib/libpthread.so.0. Does this have something to do with ldd not
listing libpthread as a shared lib? Or perhaps something with
libpthread really being stripped (but file shows otherwise)?
This is quite perplexing, and I would appreciate any help!
Regards,
Andrew L.
next prev parent reply other threads:[~2008-10-29 1:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-28 0:25 Andrew Lofthouse
2008-10-28 0:42 ` Paul Pluzhnikov
[not found] ` <4906615E.50606@gmail.com>
[not found] ` <8ac60eac0810271836saf8c28pb1392b77c7926be0@mail.gmail.com>
2008-10-29 1:16 ` Andrew Lofthouse [this message]
2008-10-29 1:52 ` Daniel Jacobowitz
2008-10-29 2:21 ` Paul Pluzhnikov
2008-10-30 1:11 ` Andrew Lofthouse
2008-10-30 1:30 ` Paul Pluzhnikov
2008-11-01 2:30 ` Andrew Lofthouse
2008-11-01 6:47 ` Paul Pluzhnikov
2008-11-01 15:29 ` Andrew Lofthouse
2008-11-01 21:41 ` Paul Pluzhnikov
2008-11-02 12:54 ` Andrew Lofthouse
2008-11-04 0:50 ` Tom Tromey
2008-12-12 22:50 ` Tom Tromey
2008-12-12 23:04 ` Daniel Jacobowitz
2008-12-12 23:30 ` Tom Tromey
2008-12-18 19:36 ` Michael Snyder
2008-12-12 23:06 ` Paul Pluzhnikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4907B915.5040101@gmail.com \
--to=loftyhauser@gmail.com \
--cc=ajloft@umich.edu \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox