From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-19310-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 6262 invoked by alias); 2 Sep 2004 14:07:35 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 6232 invoked from network); 2 Sep 2004 14:07:32 -0000
Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177)
  by sourceware.org with SMTP; 2 Sep 2004 14:07:32 -0000
Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0);
	 Thu, 2 Sep 2004 15:05:09 +0100
From: "Dave Korn" <dk@artimi.com>
To: "'Fabian Cenedese'" <Cenedese@indel.ch>,
	<gdb@sources.redhat.com>,
	"'Craig Jeffree'" <craig.jeffree@preston.net>
Subject: RE: gdb 6.1.1 (PPC) crash (long) AND gdb crash in  cp_print_class_method
Date: Thu, 02 Sep 2004 14:07: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.20040902143134.01d44e20@NT_SERVER>
Message-ID: <NUTMEGiiGv0mBZhoiUp000010db@NUTMEG.CAM.ARTIMI.COM>
X-OriginalArrivalTime: 02 Sep 2004 14:05:09.0546 (UTC) FILETIME=[DB6568A0:01C490F5]
X-SW-Source: 2004-09/txt/msg00016.txt.bz2

> -----Original Message-----
> From: gdb-owner On Behalf Of Fabian Cenedese
> Sent: 02 September 2004 13:59

> Just out of curiosity I also tried gdb-5.3 on cygwin. This 
> works without crashing:
> 
> GNU gdb 5.3
> (gdb) ptype CMainTask
> type = class CMainTask : public CINOSTask {
>   public:
>     CMainTask & operator=(CMainTask const &);
>     CMainTask(CMainTask const &);
>     virtual ~CMainTask(void);
>     CMainTask(char *, unsigned long, unsigned long);
>     virtual void Action(void);
> }
> 
> So it looks like the error was introduced in stepping from 5.3 to 6.0.

  Or perhaps as a consequence of the C++ ABI changes between gcc 2.9x and
gcc 3.x, or recent improvements and upgrading of dwarf handling.

  Craig, is your code also compiled using an old gcc 2.95 as well, by any
chance?

> But if memory corruption is the problem this is useless 
> anyway. On the other hand
> valgrind showed no error while loading the symbol file, only 
> upon this exact command:

  Yep, the corruption happens to data in valid memory addresses (the
demangled string is stomped all over), and this is indistinguishable (from
valgrind's viewpoint) from legitimate writes to that memory area.  What
happens later to cause the SEGV is a knock-on consequence of the error: I
surmise that something is trying to parse the damaged name string, not
finding what it's looking for as a result of the name not making syntactical
sense owing to its having been overwritten; then passing the NULL pointer
that results from that failed search/parse operation to some later function
that ends up passing it to strcmp (Craig's bug) or trying to dereference it
directly (your example).


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