From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24735 invoked by alias); 29 Oct 2008 02:21:34 -0000 Received: (qmail 24727 invoked by uid 22791); 29 Oct 2008 02:21:33 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Oct 2008 02:20:41 +0000 Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id m9T2KaAO010336 for ; Wed, 29 Oct 2008 02:20:36 GMT Received: from wa-out-1112.google.com (wagm33.prod.google.com [10.114.214.33]) by spaceape12.eur.corp.google.com with ESMTP id m9T2KV60030661 for ; Tue, 28 Oct 2008 19:20:34 -0700 Received: by wa-out-1112.google.com with SMTP id m33so1692633wag.31 for ; Tue, 28 Oct 2008 19:20:31 -0700 (PDT) Received: by 10.114.131.9 with SMTP id e9mr6804644wad.194.1225246831075; Tue, 28 Oct 2008 19:20:31 -0700 (PDT) Received: by 10.114.78.12 with HTTP; Tue, 28 Oct 2008 19:20:31 -0700 (PDT) Message-ID: <8ac60eac0810281920r4bf71400hc8171bdee3c92ca@mail.gmail.com> Date: Wed, 29 Oct 2008 02:21:00 -0000 From: "Paul Pluzhnikov" To: ajloft@umich.edu Subject: Re: "Cannot find new threads" on Fedora 9, but not on CentOS 5 (?) Cc: gdb@sourceware.org In-Reply-To: <4907B915.5040101@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49065BBD.3050800@gmail.com> <8ac60eac0810271741h135f077bj2c3fcd7391e89ed7@mail.gmail.com> <4906615E.50606@gmail.com> <8ac60eac0810271836saf8c28pb1392b77c7926be0@mail.gmail.com> <4907B915.5040101@gmail.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00129.txt.bz2 On Tue, Oct 28, 2008 at 6:15 PM, Andrew Lofthouse 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 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 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 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=, thread_return=) at pthread_join.c:89 (gdb) bt #0 0x0000000000110628 in fn (p=0x0) at thread-so.c:6 #1 0x0000003c9f80729a in start_thread (arg=) 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=, thread_return=) at pthread_join.c:89 89 lll_wait_tid (pd->tid); (gdb) bt #0 0x0000003c9f807b75 in pthread_join (threadid=, thread_return=) 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