This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]