This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: "Cannot find new threads" on Fedora 9, but not on CentOS 5 (?)
On Tue, Oct 28, 2008 at 6:15 PM, Andrew Lofthouse <loftyhauser@gmail.com> 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).
The application apparently dynamically loads /tmp/gfsZ54KNU,
which in turn depends (perhaps indirectly) on libpthread.so.0
This is supposed to work in theory, but apparently has glitches on
Fedora 9, though I can't reproduce that on my x86_64 Fedora 9.
See what you get with a test case at the bottom.
As a workaround, you may try to build your ufs2oogl2D with '-pthread'.
The other thing which may provide clues is to 'set verbose on'
before running the program.
> Now I'm confused. It looks like the non-debug library is not stripped, but
> the debug library is stripped (?):
This is good: libpthread.so.0 is not 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
This isn't a library at all; this is just the debug bits for it.
Since these bits do not have a symbol table, file(1) says that it's
stripped. You can ignore that:
> [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:
It can find the symbols all right, but while GDB is adding symbols,
it hits some error, likely having to do with the process "suddenly"
becoming multithreaded.
Anyway, do you get any problems with the test case below.
What does "info threads" at crash point say?
--- cut --- thread-so-main.c ---
// compile with "gcc thread-so-main.c -ldl"
#include <dlfcn.h>
int main()
{
void *h = dlopen("./thread-so.so", RTLD_LAZY);
void (*fn)(void) = dlsym(h, "foo");
fn();
return 0;
}
--- cut ---
--- cut --- thread-so.c ---
// compile with "gcc -g -fPIC -shared -o thread-so.so thread-so.c
/lib/libgthread-2.0.so.0"
#include <pthread.h>
void *fn(void *p)
{
char *cp = (char *)p;
cp[0] = 'a';
return p;
}
void foo()
{
pthread_t tid;
pthread_create(&tid, 0, fn, 0);
pthread_join(tid, 0);
}
--- cut ---
For reference, here is what I see (all good):
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"...
(no debugging symbols found)
(gdb) r
Starting program: /mnt/ppluzhnikov/tmp/a.out
[Thread debugging using libthread_db enabled]
[New Thread 0x7f1a2d0136f0 (LWP 3004)]
[New Thread 0x416de950 (LWP 3007)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x416de950 (LWP 3007)]
0x0000000000110628 in fn (p=0x0) at thread-so.c:6
6 cp[0] = 'a';
Missing separate debuginfos, use: debuginfo-install glib2.x86_64
libselinux.x86_64
(gdb) inf thread
* 2 Thread 0x416de950 (LWP 3007) 0x0000000000110628 in fn (p=0x0) at
thread-so.c:6
1 Thread 0x7f1a2d0136f0 (LWP 3004) 0x0000003c9f807b75 in
pthread_join (threadid=<value optimized out>, thread_return=<value
optimized out>)
at pthread_join.c:89
(gdb) bt
#0 0x0000000000110628 in fn (p=0x0) at thread-so.c:6
#1 0x0000003c9f80729a in start_thread (arg=<value optimized out>) at
pthread_create.c:297
#2 0x0000003c9e8e42cd in clone () from /lib64/libc.so.6
(gdb) thread 1
[Switching to thread 1 (Thread 0x7f1a2d0136f0 (LWP 3004))]#0
0x0000003c9f807b75 in pthread_join (threadid=<value optimized out>,
thread_return=<value optimized out>) at pthread_join.c:89
89 lll_wait_tid (pd->tid);
(gdb) bt
#0 0x0000003c9f807b75 in pthread_join (threadid=<value optimized
out>, thread_return=<value optimized out>) at pthread_join.c:89
#1 0x0000000000110661 in foo () at thread-so.c:14
#2 0x000000000040059f in main ()
(gdb) q
The program is running. Exit anyway? (y or n) y
--
Paul Pluzhnikov