gdb bugs showing while working on libcwd

[Carlo Wood <carlo at alinoe dot com>]

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 <carlo@alinoe.com>