Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <NUTMEGiiGv0mBZhoiUp000010db@NUTMEG.CAM.ARTIMI.COM> (raw)
In-Reply-To: <5.2.0.9.1.20040902143134.01d44e20@NT_SERVER>

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


  reply	other threads:[~2004-09-02 14:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-01  9:01 gdb 6.1.1 (PPC) crash (long) Fabian Cenedese
2004-09-01  9:18 ` Fabian Cenedese
2004-09-02 12:20   ` gdb 6.1.1 (PPC) crash (long) AND gdb crash in cp_print_class_method Dave Korn
2004-09-02 12:59     ` Fabian Cenedese
2004-09-02 14:07       ` Dave Korn [this message]
2004-09-02 22:48         ` Craig Jeffree
2004-09-07 14:41           ` Dave Korn
2004-09-02 11:59 ` gdb 6.1.1 (PPC) crash (long) Fabian Cenedese
2004-09-07 14:50   ` Daniel Jacobowitz
     [not found] ` <5.2.0.9.1.20040907170934.01d457f8@NT_SERVER>
2004-09-07 17:02   ` Daniel Jacobowitz
2004-09-29  5:27     ` Craig Jeffree

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=NUTMEGiiGv0mBZhoiUp000010db@NUTMEG.CAM.ARTIMI.COM \
    --to=dk@artimi.com \
    --cc=Cenedese@indel.ch \
    --cc=craig.jeffree@preston.net \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox