From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13369 invoked by alias); 2 Sep 2004 12:59:20 -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 13352 invoked from network); 2 Sep 2004 12:59:18 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 2 Sep 2004 12:59:18 -0000 Received: from indel.ch (217-162-27-127.dclient.hispeed.ch [217.162.27.127]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with SMTP id i82CxHd7021946 for ; Thu, 2 Sep 2004 14:59:17 +0200 Received: from fabi.indel.ch [192.168.1.19] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Thu, 02 Sep 2004 14:58:02 +0200 Message-Id: <5.2.0.9.1.20040902143134.01d44e20@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Thu, 02 Sep 2004 12:59:00 -0000 To: From: Fabian Cenedese Subject: RE: gdb 6.1.1 (PPC) crash (long) AND gdb crash in cp_print_class_method In-Reply-To: References: <5.2.0.9.1.20040901111203.01d35778@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sources.redhat.com X-Return-Path: cenedese@indel.ch X-SW-Source: 2004-09/txt/msg00015.txt.bz2 > 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