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

Dave Korn
2004-09-02T12:20:12Z

> -----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....