RE: gdb 6.1.1 (PPC) crash (long) AND gdb crash in cp_print_class_method

["Dave Korn" <dk@artimi.com>]

> -----Original Message-----
> From: gdb-owner On Behalf Of Fabian Cenedese
> Sent: 01 September 2004 10:18
> To: gdb
> Subject: Re: gdb 6.1.1 (PPC) crash (long)

[...snip!...]

> (gdb) frame 2
> #2  0x004dda6c in c_type_print_base (type=0xa2b4b68, stream=0xa084088,
>     show=1, level=0) at ../../gdb-6.1.1/gdb/c-typeprint.c:952
> 952                       int is_full_physname_constructor =
> (gdb) info locals

[...snip!...]

> mangled_name = 0xa297650 "_._9CMainTask"
> demangled_name = 0xa28da58 "X\203)\nE\203)\nk::~CMainTask(void)"

[...snip!...]

> Is this supposed to look like that?
> 
> demangled_name = 0xa28da58 "X\203)\nE\203)\nk::~CMainTask(void)"



> -----Original Message-----
> From: gdb-owner On Behalf Of Craig Jeffree
> Sent: 02 September 2004 00:48
> To: gdb
> Subject: gdb crash in cp_print_class_method

[...snip!...]

> Crash 1
> =======
> (gdb) bt
> #0  0xb74b0e7a in strcmp () from /lib/tls/libc.so.6
> #1  0x0814d00f in cp_print_class_method (
>     valaddr=0x15a88b68 "\030\214W\bnline/taam/src/m!", 
> type=0x15ab6c48,
>     stream=0x8283740) at cp-valprint.c:134
> #2  0x0814ca69 in c_val_print (type=0x11361658,
>     valaddr=0x15b2d3f8 "??4\bodel/dynamicX", embedded_offset=0,
>     address=139955224, stream=0x8283740, format=0, deref_ref=1,
> recurse=0,
>     pretty=Val_prettyprint) at c-valprint.c:449
> #3  0x080dbc40 in val_print (type=0x11361658,
>     valaddr=0x15b2d3f8 "??4\bodel/dynamicX", embedded_offset=0,
>     address=139955224, stream=0x8283740, format=0, deref_ref=1,
> recurse=0,
>     pretty=Val_pretty_default) at ./valprint.c:149


  Gentlemen, you seem very likely to have stumbled across the same problem.
There is clearly something very very wrong in the C++ demangling and pretty
printing.  Last time I checked the bfd demangler had no regressions in it,
so I think it's fairly likely that something is stomping over the demangled
string after it's been returned to cp_print_class_method by bfd, and this is
causing a later failure when the damaged data is passed to strcmp or
is_constructor_name.  It might be possible to debug this by a clever
combination of scripting and setting hardware memory watchpoints to try and
catch anything changing the relevant memory area apart from the
demangler.... 

  Fabian, about a point from your first email:  the addresses in .stackdump
files are always raw, even from a debug build of the code; the
stackdump-writing code is quite simple and doesn't look them up for you.
You can use 'addr2line' from binutils to decode the "Function" addresses it
shows; check the man/info page for more.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....