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

Dave Korn
2004-09-02T14:07:35Z

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