From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15552 invoked by alias); 24 May 2002 00:35:56 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15510 invoked from network); 24 May 2002 00:35:53 -0000 Received: from unknown (HELO mail.alinoe.com) (24.132.80.10) by sources.redhat.com with SMTP; 24 May 2002 00:35:53 -0000 Received: (qmail 5787 invoked by uid 500); 24 May 2002 00:35:46 -0000 Date: Thu, 23 May 2002 17:35:00 -0000 From: Carlo Wood To: Liam Stewart Cc: gdb@sources.redhat.com Subject: gdb bugs showing while working on libcwd Message-ID: <20020524023546.A19030@alinoe.com> References: <20020522115242.C28512@redhat.com> <20020523153816.A4454@alinoe.com> <20020523094527.B25730@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020523094527.B25730@redhat.com>; from liams@redhat.com on Thu, May 23, 2002 at 09:45:27AM -0400 X-SW-Source: 2002-05/txt/msg00266.txt.bz2 On Thu, May 23, 2002 at 09:45:27AM -0400, Liam Stewart wrote: > Thanks for the info, Carlo. I'm going to CC this thread to the public > gdb mailing list hosted at sources.redhat.com, if that's alright with > you. Weird, didn't find this mailinglist at first (a week ago thus). Instead, I subscribed to 'bug-gdb@gnu.org'. Anyway - here is the first problem. Let me know if you can reproduce it. CVS Tag : gdbbug00 $ cd libcwd $ cvs update -r gdbbug00 Configuration: (its best to rerun bootstrap after a cvs update command). $ ./bootstrap $ CXX="g++-3.0.4" CC="gcc-3.0.4" ./configure --enable-maintainer-mode --enable-debug --enable-debugt --enable-debugm --disable-debug-output [ Please note that "g++-3.0.4" is a script that I use in order to make sure that the resulting applications use the correct libstdc++ by adding "-Wl,-rpath,/usr/local/gcc-3.0.4/lib:$LD_RUN_PATH" to the commandline (where /usr/local/gcc-3.0.4) is my installation prefix. Alternatively you can set LD_LIBRARY_PATH prior to run executables of course. ] Next compile libcwd: $ make And a test application: $ cd testsuite $ make module_r.so $ make threads_threads_shared Next run threads_threads_shared (possibly a few times) until it aborts. For example: ~/c++/libcwd/testsuite>threads_threads_shared 1026 (0002) BAR : Enabled 1026 (0002) BFD : Disabled 1026 (0002) DEBUG : Disabled ... 10251 (0011) COREDUMP: Deleting a marker must be done in the same "scope" as where it was allocated; for example, you cannot allocate marker A, then allocate marker B and then delete marker A before deleting first marker B. ... Aborted There should only be one 'COREDUMP' line and it should say what it says here. There can be any number of lines after the coredump line before the application really aborts however. You now should have a core file. Here is what I next do what reveals a problem with gdb: ~/c++/libcwd/testsuite>gdb threads_threads_shared core.21920 GNU gdb Red Hat Linux (5.1-1) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... warning: core file may not match specified executable file. Core was generated by `threads_threads_shared'. Program terminated with signal 6, Aborted. Reading symbols from /home/carlo/c++/libcwd/.libs/libcwd_r.so.0...done. Loaded symbols for /home/carlo/c++/libcwd/.libs/libcwd_r.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/local/gcc-3.0.4/lib/libstdc++.so.3...done. Loaded symbols for /usr/local/gcc-3.0.4/lib/libstdc++.so.3 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/local/gcc-3.0.4/lib/libgcc_s.so.1...done. Loaded symbols for /usr/local/gcc-3.0.4/lib/libgcc_s.so.1 Reading symbols from /lib/libpthread.so.0...done. warning: Unable to set global thread event mask: generic error [New Thread 1024 (LWP 21868)] Error while reading shared library symbols: Can't attach LWP 21868: No such process Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x4034b171 in __kill () from /lib/libc.so.6 (gdb) bt #0 0x4034b171 in __kill () from /lib/libc.so.6 #1 0x40315e42 in raise (sig=6) at signals.c:65 #2 0x4008167c in libcw::debug::core_dump() () at debug.cc:642 #3 0x40082d5c in libcw::debug::debug_tsd_st::finish(libcw::debug::debug_ct&, libcw::debug::channel_set_data_st&, libcw::debug::_private_::TSD_st&) (this=0x82249a8, debug_object=@0x80842a8, channel_set=@0xbe5ff90c, __libcwd_tsd=@0x80877e4) at debug.cc:1014 #4 0x400831e3 in libcw::debug::debug_tsd_st::fatal_finish(libcw::debug::debug_ct&, libcw::debug::channel_set_data_st&, libcw::debug::_private_::TSD_st&) (this=0x82249a8, debug_object=@0x80842a8, channel_set=@0xbe5ff90c, __libcwd_tsd=@0x0) at debug.cc:1104 #5 0x40091c24 in libcw::debug::marker_ct::~marker_ct() (this=0x834e530) at debugmalloc.cc:2301 #6 0x0806a32e in leak_prog(void*) () at libcwd.tst/leak.cc:145 #7 0x4031308b in pthread_start_thread (arg=0xbe5ffbe0) at manager.c:284 (gdb) thread [Current thread is 1 (process 21920)] (gdb) thread 2 Couldn't get registers: No such process. (gdb) thread 1 Couldn't get registers: No such process. (gdb) The bug is that after trying 'thread 2', there is no way to return to 'thread 1' again. If you have "problems" with the fact that I am using gdb 5.1, then I am willing to use 5.2 or the latest cvs version; I tried that before however and it was totally unusable... so the problems with that will be different ;). -- Carlo Wood