From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21894 invoked by alias); 2 Sep 2004 12:20:12 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21874 invoked from network); 2 Sep 2004 12:20:09 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sourceware.org with SMTP; 2 Sep 2004 12:20:09 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 13:17:49 +0100 From: "Dave Korn" To: "'Fabian Cenedese'" , , "'Craig Jeffree'" Subject: RE: gdb 6.1.1 (PPC) crash (long) AND gdb crash in cp_print_class_method Date: Thu, 02 Sep 2004 12:20:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <5.2.0.9.1.20040901111203.01d35778@NT_SERVER> Message-ID: X-OriginalArrivalTime: 02 Sep 2004 12:17:49.0187 (UTC) FILETIME=[DCA49D30:01C490E6] X-SW-Source: 2004-09/txt/msg00014.txt.bz2 > -----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....