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

[Fabian Cenedese <Cenedese at indel dot ch>]

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

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.

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

Thanks for the hint, I've already wondered what this tool is for :) In this case
it was not necessary as I managed to get a backtrace with running gdb
in gdb. A short test showed that the addresses are the same as in this
backtrace.


(gdb) bt
#0  gnuv2_is_constructor_name (name=0x0)
    at ../../gdb-6.1.1/gdb/gnu-v2-abi.c:56
#1  0x00488bf8 in is_constructor_name (name=0x0)
    at ../../gdb-6.1.1/gdb/cp-abi.c:44
#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
#3  0x004dc816 in c_print_type (type=0xa2b4b68, varstring=0x716c4d "",
    stream=0xa084088, show=1, level=0) at ../../gdb-6.1.1/gdb/c-typeprint.c:75
#4  0x004945af in type_print (type=0xa2b4b68, varstring=0x716c4d "",
    stream=0xa084088, show=1) at ../../gdb-6.1.1/gdb/typeprint.c:109
#5  0x0049482a in ptype_command (typename=0xa05180e "CMainTask", from_tty=1)
    at ../../gdb-6.1.1/gdb/typeprint.c:223
etc


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:


(gdb) file ~/tmp/dbg.x
Reading symbols from ~/tmp/dbg.x...done.
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) ptype CMainTask
type = class CMainTask : public CINOSTask {
 public:
   CMainTask & operator=(CMainTask const &);
   virtual ~CMainTask(void);
==26478== Invalid read of size 1
==26478==    at 0x8171B62: gnuv2_is_constructor_name (gnu-v2-abi.c:56)
==26478==    by 0x8085637: is_constructor_name (cp-abi.c:44)
==26478==    by 0x8160D5B: c_type_print_base (c-typeprint.c:952)
==26478==    by 0x815FAE5: c_print_type (c-typeprint.c:75)
==26478==    by 0x815F57E: type_print (typeprint.c:109)
==26478==    by 0x815F7F9: ptype_command (typeprint.c:223)
==26478==    by 0x80ADF78: do_cfunc (cli-decode.c:57)
==26478==    by 0x80AFE6B: cmd_func (cli-decode.c:1541)
==26478==    by 0x807F7E5: execute_command (top.c:743)
==26478==    by 0x810BC3E: command_handler (event-top.c:500)
==26478==    by 0x810C084: command_line_handler (event-top.c:793)
==26478==    by 0x81E0EA4: rl_callback_read_char (callback.c:123)
==26478==    by 0x810B58A: rl_callback_read_char_wrapper (event-top.c:166)
==26478==    by 0x810BB39: stdin_event_handler (event-top.c:416)
==26478==    by 0x810AE1D: handle_file_event (event-loop.c:721)
==26478==    by 0x810A8D8: process_event (event-loop.c:334)
==26478==    by 0x810A937: gdb_do_one_event (event-loop.c:371)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x80BC733: tui_command_loop (tui-interp.c:150)
==26478==    by 0x8108648: current_interp_command_loop (interps.c:277)
==26478==    by 0x807A91A: captured_command_loop (main.c:97)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x807B2E3: captured_main (main.c:805)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x807B762: gdb_main (main.c:814)
==26478==    by 0x807A8FD: main (gdb.c:35)
==26478==  Address 0x0 is not stack'd, malloc'd or free'd
==26478==
==26478== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==26478==  Access not within mapped region at address 0x0
==26478==    at 0x8171B62: gnuv2_is_constructor_name (gnu-v2-abi.c:56)
==26478==    by 0x8085637: is_constructor_name (cp-abi.c:44)
==26478==    by 0x8160D5B: c_type_print_base (c-typeprint.c:952)
==26478==    by 0x815FAE5: c_print_type (c-typeprint.c:75)
==26478==    by 0x815F57E: type_print (typeprint.c:109)
==26478==    by 0x815F7F9: ptype_command (typeprint.c:223)
==26478==    by 0x80ADF78: do_cfunc (cli-decode.c:57)
==26478==    by 0x80AFE6B: cmd_func (cli-decode.c:1541)
==26478==    by 0x807F7E5: execute_command (top.c:743)
==26478==    by 0x810BC3E: command_handler (event-top.c:500)
==26478==    by 0x810C084: command_line_handler (event-top.c:793)
==26478==    by 0x81E0EA4: rl_callback_read_char (callback.c:123)
==26478==    by 0x810B58A: rl_callback_read_char_wrapper (event-top.c:166)
==26478==    by 0x810BB39: stdin_event_handler (event-top.c:416)
==26478==    by 0x810AE1D: handle_file_event (event-loop.c:721)
==26478==    by 0x810A8D8: process_event (event-loop.c:334)
==26478==    by 0x810A937: gdb_do_one_event (event-loop.c:371)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x80BC733: tui_command_loop (tui-interp.c:150)
==26478==    by 0x8108648: current_interp_command_loop (interps.c:277)
==26478==    by 0x807A91A: captured_command_loop (main.c:97)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x807B2E3: captured_main (main.c:805)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x807B762: gdb_main (main.c:814)
==26478==    by 0x807A8FD: main (gdb.c:35)
==26478==
==26478== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 24 from 2)
==26478== malloc/free: in use at exit: 742482 bytes in 4289 blocks.
==26478== malloc/free: 10558 allocs, 6269 frees, 1079443 bytes allocated.
==26478== For a detailed leak analysis,  rerun with: --leak-check=yes
==26478== For counts of detected errors, rerun with: -v
Segmentation fault

Thanks

bye  Fabi