This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
SIGSEGV in gdb 6.4 debugging gcc 2.95 stabs, with possible fix
- From: Simon Baldwin <simon_baldwin at yahoo dot com>
- To: gdb at sourceware dot org
- Date: Fri, 5 May 2006 12:41:43 -0700 (PDT)
- Subject: SIGSEGV in gdb 6.4 debugging gcc 2.95 stabs, with possible fix
gdb 6.4 SIGSEGVs with g++ 2.95.3 built binaries that happen to have a
particular layout of virtual functions in a given class. For example:
$ cat vf.cc
class Foo {
public:
virtual ~Foo() {}
Foo() {}
};
int main() {
Foo f;
}
$ gcc-2.95.3-glibc-2.2.2 -x c++ -pedantic -g -o vf vf.cc
$ gdb-6.4/gdb/gdb /tmp/vf
GNU gdb 6.4
Copyright 2005 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 "i686-pc-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) break Foo::Foo
Segmentation fault
Running gdb within gdb reveals
Program received signal SIGSEGV, Segmentation fault.
gnuv2_is_destructor_name (name=0x0) at gnu-v2-abi.c:45
45 if ((name[0] == '_' && is_cplus_marker (name[1]) && name[2] ==
'_')
The cause turns out to be an unset element in the field lists passed to
add_matching_methods() in linespec.c. The actual unset element occurs
because of mismatch can occur between the sublist length and the value of
'length' at lines 2549 and later in stabsread.c. Here, an array of 'length'
elements is allocated (and zeroed), but fewer elements are then copied in by
the loop at line 2554.
The fix, while a long way from the problem symptom, is, I believe:
*** /local/gdb/gdb-6.4/gdb/stabsread.c 2005-07-04 06:29:12.000000000 -0700
--- ./stabsread.c 2006-05-05 12:22:02.000000000 -0700
***************
*** 2492,2497 ****
--- 2492,2498 ----
{
if (!is_destructor_name (tmp_sublist->fn_field.physname))
{
+ last_sublist = tmp_sublist;
tmp_sublist = tmp_sublist->next;
continue;
}
Is this a known problem? If not, does the above look like a good candidate
patch?
Thanks.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com