From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29829 invoked by alias); 1 Nov 2008 02:30:11 -0000 Received: (qmail 29700 invoked by uid 22791); 1 Nov 2008 02:30:07 -0000 X-Spam-Check-By: sourceware.org Received: from yx-out-1718.google.com (HELO yx-out-1718.google.com) (74.125.44.157) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Nov 2008 02:29:14 +0000 Received: by yx-out-1718.google.com with SMTP id 3so873691yxi.48 for ; Fri, 31 Oct 2008 19:29:12 -0700 (PDT) Received: by 10.90.50.5 with SMTP id x5mr10101866agx.92.1225506551035; Fri, 31 Oct 2008 19:29:11 -0700 (PDT) Received: from ?192.168.10.3? (cpe-71-67-134-86.woh.res.rr.com [71.67.134.86]) by mx.google.com with ESMTPS id 34sm4460356agc.6.2008.10.31.19.29.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Oct 2008 19:29:10 -0700 (PDT) Message-ID: <490BBEF4.1040801@gmail.com> Date: Sat, 01 Nov 2008 02:30:00 -0000 From: Andrew Lofthouse Reply-To: ajloft@umich.edu User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: "Cannot find new threads" on Fedora 9, but not on CentOS 5 (?) References: <49065BBD.3050800@gmail.com> <8ac60eac0810271741h135f077bj2c3fcd7391e89ed7@mail.gmail.com> <4906615E.50606@gmail.com> <8ac60eac0810271836saf8c28pb1392b77c7926be0@mail.gmail.com> <4907B915.5040101@gmail.com> <8ac60eac0810281920r4bf71400hc8171bdee3c92ca@mail.gmail.com> <490909B3.2080307@gmail.com> <8ac60eac0810291830g46604c3eye8365240c48007d0@mail.gmail.com> In-Reply-To: <8ac60eac0810291830g46604c3eye8365240c48007d0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-11/txt/msg00000.txt.bz2 Paul Pluzhnikov wrote: > You can tell: for each library in ldd output on Fedora 9, namely: > > /usr/local/lib/libufs2D-0.9.so.2 > /usr/local/lib/libgts-0.7.so.5 > /lib/libgmodule-2.0.so.0 > /lib/libdl.so.2 > /lib/libglib-2.0.so.0 > /lib/libselinux.so.1 > > do 'ldd /path/to/lib' on CentOS. > At least one of them (I expect) will show libpthread.so.0 dependency, > which implies that they were built differently. Yes, /lib/libglib-2.0.so.0 depends on libpthread.so.0 > >> And, yet, it handles your test case as well... > > Since we can't replicate "bad GDB behavior" on a test case, I am > afraid the only way forward is for you to debug gdb with itself. Last night I tried to follow your example and try to debug gdb, but to do so, I would have to replicate my earlier problem, but I was unable to do so (meaning, gdb did not have any problems following the new threads, or finding libpthread symbols). I thought this was because I had explicitly linked with -pthread previously. I rebooted, rebuilt, and was still unable to replicate the problem. I re-installed Fedora 9 from scratch, and I'm still unable to replicate it. I have no idea what changed. Ubuntu 8.04, however, still gives a "cannot find new threads: generic error" when not explicitly linking to libpthread. So, the following comes from Ubuntu. Unfortunately, I cannot find any debug symbols for gdb for Ubuntu (Fedora seems to have them). For what it's worth: ==> andrew@ubuntu-vm ~/codes/ufs Fri Oct 31 22:17:01 532 $ gdb -ex 'set prompt (top) ' --args gdb /usr/local/bin/ufs2oogl2D GNU gdb 6.8-debian 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 "i486-linux-gnu"... (no debugging symbols found) (top) rbreak throw_ Breakpoint 1 at 0x8132024 throw_exception; Breakpoint 2 at 0x8132136 throw_error; Breakpoint 3 at 0x8132158 throw_vfatal; Breakpoint 4 at 0x8132176 throw_verror; Breakpoint 5 at 0x8132196 deprecated_throw_reason; (top) run Starting program: /usr/bin/gdb /usr/local/bin/ufs2oogl2D (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 0xb7d396b0 (LWP 31952)] GNU gdb 6.8-debian 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 "i486-linux-gnu"... (gdb) set verbose on (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 Reading symbols from /lib/ld-linux.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...done. done. Reading symbols from system-supplied DSO at 0xb7f0e000...done. Reading symbols from /usr/local/lib/libufs2D-0.9.so.2...done. Reading symbols from /usr/local/lib/libgts-0.7.so.5...done. Reading symbols from /usr/lib/libgmodule-2.0.so.0...Reading symbols from /usr/lib/debug/usr/lib/libgmodule-2.0.so.0.1600.6...done. done. Reading symbols from /usr/lib/debug/libdl.so.2...done. Reading symbols from /usr/lib/libglib-2.0.so.0...Reading symbols from /usr/lib/debug/usr/lib/libglib-2.0.so.0.1600.6...done. done. Reading symbols from /usr/lib/debug/libm.so.6...done. Reading symbols from /usr/lib/debug/libc.so.6...done. Reading symbols from /usr/lib/libpcre.so.3...Reading symbols from /usr/lib/debug/usr/lib/libpcre.so.3.12.1...done. done. Detaching after fork from child process 31962. Reading symbols from /tmp/gfs2O2C03...done. Reading symbols from /usr/lib/libgthread-2.0.so.0...Reading symbols from /usr/lib/debug/usr/lib/libgthread-2.0.so.0.1600.6...done. done. Reading symbols from /usr/lib/debug/librt.so.1...done. Reading symbols from /usr/lib/debug/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [Switching to Thread 0xb7d396b0 (LWP 31952)] Breakpoint 4, 0x08132176 in throw_verror () (top) where #0 0x08132176 in throw_verror () #1 0x0808f403 in error () #2 0x080a2580 in ?? () #3 0x080a3d4e in check_for_thread_db () #4 0x0808782f in ?? () #5 0x08087987 in observer_notify_new_objfile () #6 0x08119aaa in ?? () #7 0x0809aad0 in ?? () #8 0x08132393 in catch_errors () #9 0x0809a69c in solib_read_symbols () #10 0x0809b062 in solib_add () #11 0x081284eb in handle_inferior_event () #12 0x08129f77 in wait_for_inferior () #13 0x0812a147 in proceed () #14 0x08124dc3 in ?? () #15 0x0808b531 in execute_command () #16 0x08135dff in ?? () #17 0x08136b53 in ?? () #18 0xb7f27962 in rl_callback_read_char () from /lib/libreadline.so.5 #19 0x08135fcb in ?? () #20 0x0813594e in ?? () ---Type to continue, or q to quit--- #21 0x08134d90 in ?? () #22 0x08135630 in gdb_do_one_event () #23 0x08132393 in catch_errors () #24 0x080d63c4 in ?? () #25 0x0813299f in current_interp_command_loop () #26 0x0808330b in ?? () #27 0x08132393 in catch_errors () #28 0x08083c0c in ?? () #29 0x08132393 in catch_errors () #30 0x080832f1 in gdb_main () #31 0x080832b5 in main () (top) If I have some more time, I'll see what else I can do. But, I do at least have a work-around... Regards, Andrew