This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: c++/1069: Issues printing derived objects with gdb


The following reply was made to PR c++/1069; it has been noted by GNATS.

From: Daniel Jacobowitz <drow at mvista dot com>
To: gdb-gnats at sources dot redhat dot com
Cc:  
Subject: RE: c++/1069: Issues printing derived objects with gdb
Date: Mon, 3 Mar 2003 14:58:39 -0500

 ----- Forwarded message from Monte Becker <monte at juniper dot net> -----
 
 Date: Fri, 21 Feb 2003 08:24:58 -0500
 From: "Monte Becker" <monte at juniper dot net>
 Subject: RE: c++/1069: Issues printing derived objects with gdb
 To: "Daniel Jacobowitz" <drow at mvista dot com>
 
 
 Where you able to get this failure using my test case?
 
 I make a break point at find_overload_match, and here is the stack:
 
    (top-gdb) where
 #0  find_overload_match (arg_types=0xffbed2b0, nargs=0x1, name=0xffbed370 "gen", method=0x1, lax=0x1, objp=0xffbed308, fsym=0x0, valp=0xffbed304, symp=0x0, staticp=0xffbed300) at ../../gdb/valops.c:2685
 #1  0x00062620 in evaluate_subexp_standard (expect_type=0x0, exp=0x360e08, pos=0xffbed564, noside=EVAL_NORMAL) at ../../gdb/eval.c:841
 #2  0x00060d98 in evaluate_subexp (expect_type=0x0, exp=0x56, pos=0xffbed564, noside=EVAL_NORMAL) at ../../gdb/eval.c:70
 #3  0x00060f30 in evaluate_expression (exp=0x360e08) at ../../gdb/eval.c:159
 #4  0x0007028c in print_command_1 (exp=0x2722d2 "c.gen()", inspect=0x0, voidprint=0x1) at ../../gdb/printcmd.c:907
 #5  0x000703ec in print_command (exp=0x2722d2 "c.gen()", from_tty=0x1) at ../../gdb/printcmd.c:951
 #6  0x00041f2c in do_cfunc (c=0x27c470, args=0x2722d2 "c.gen()", from_tty=0x1) at ../../gdb/cli/cli-decode.c:53
 #7  0x00043ad0 in cmd_func (cmd=0x27c470, args=0x2722d2 "c.gen()", from_tty=0x1) at ../../gdb/cli/cli-decode.c:1531
 #8  0x000da128 in execute_command (p=0x2722d8 ")", from_tty=0x1) at ../../gdb/top.c:711
 #9  0x00090f48 in command_handler (command=0x2722d0 "p c.gen()") at ../../gdb/event-top.c:502
 #10 0x00091648 in command_line_handler (rl=0x26f400 "") at ../../gdb/event-top.c:797
 #11 0x001a6888 in rl_callback_read_char () at ../../readline/callback.c:123
 #12 0x000906bc in rl_callback_read_char_wrapper (client_data=0x0) at ../../gdb/event-top.c:166
 #13 0x00090dec in stdin_event_handler (error=0x0, client_data=0x0) at ../../gdb/event-top.c:416
 #14 0x0008fde8 in handle_file_event (event_file_desc=0x1) at ../../gdb/event-loop.c:721
 #15 0x0008f734 in process_event () at ../../gdb/event-loop.c:334
 #16 0x0008f784 in gdb_do_one_event (data=0x1) at ../../gdb/event-loop.c:371
 #17 0x000d9d38 in do_catch_errors (uiout=0x28ff08, data=0xffbedd08) at ../../gdb/top.c:492
 #18 0x000d9be0 in catcher (func=0xd9d28 <do_catch_errors>, func_uiout=0x28ff08, func_args=0xffbedd08, func_val=0xffbedd04, func_caught=0xffbedd00, errstring=0x1dee50 "", mask=0x6) at ../../gdb/top.c:424
 #19 0x000d9d74 in catch_errors (func=0x8f748 <gdb_do_one_event>, func_args=0x0, errstring=0x1dee50 "", mask=0x6) at ../../gdb/top.c:504
 #20 0x0008f7dc in start_event_loop () at ../../gdb/event-loop.c:422
 #21 0x000907c4 in cli_command_loop () at ../../gdb/event-top.c:198
 #22 0x0008f224 in current_interp_command_loop () at ../../gdb/interps.c:281
 #23 0x0003f970 in captured_command_loop (data=0x1) at ../../gdb/main.c:97
 #24 0x000d9d38 in do_catch_errors (uiout=0x28ff08, data=0xffbee098) at ../../gdb/top.c:492
 #25 0x000d9be0 in catcher (func=0xd9d28 <do_catch_errors>, func_uiout=0x28ff08, func_args=0xffbee098, func_val=0xffbee094, func_caught=0xffbee090, errstring=0x1c5310 "", mask=0x6) at ../../gdb/top.c:424
 #26 0x000d9d74 in catch_errors (func=0x3f964 <captured_command_loop>, func_args=0x0, errstring=0x1c5310 "", mask=0x6) at ../../gdb/top.c:504
 #27 0x000405dc in captured_main (data=0xffbee7af) at ../../gdb/main.c:788
 #28 0x000d9d38 in do_catch_errors (uiout=0x250ea0, data=0xffbee430) at ../../gdb/top.c:492
 #29 0x000d9be0 in catcher (func=0xd9d28 <do_catch_errors>, func_uiout=0x250ea0, func_args=0xffbee430, func_val=0xffbee42c, func_caught=0xffbee428, errstring=0x1c5310 "", mask=0x6) at ../../gdb/top.c:424
 #30 0x000d9d74 in catch_errors (func=0x3f9a4 <captured_main>, func_args=0xffbee518, errstring=0x1c5310 "", mask=0x6) at ../../gdb/top.c:504
 #31 0x000407f4 in gdb_main (args=0xffbee518) at ../../gdb/main.c:797
 #32 0x0003f95c in main (argc=0x2, argv=0xffbee59c) at ../../gdb/gdb.c:35
 (top-gdb) 
 
 > -----Original Message-----
 > From: Daniel Jacobowitz [mailto:drow at mvista dot com]
 > Sent: Thursday, February 20, 2003 10:11 PM
 > To: Monte Becker
 > Subject: Re: c++/1069: Issues printing derived objects with gdb
 > 
 > 
 > On Wed, Feb 19, 2003 at 02:48:37PM -0500, Monte Becker wrote:
 > > 
 > > Owch...
 > > 
 > > 	I had to use the new version of GDB to get the stack 
 > dump.  This is hurting my head!
 > > 
 > > 	Anyhow, here's the stack below.  BTW, in my large 
 > program, I can easily reproduce the
 > > "print causes program to continue" bug.
 > 
 > That one really, really confuses me.  I'm sorry but I don't have any
 > idea where to start looking.
 > 
 > > (gdb) p c.gen()
 > > 
 > > Program received signal SIGSEGV, Segmentation fault.
 > > 0x7f933344 in strlen () from /usr/lib/libc.so.1
 > > (gdb) where
 > > #0  0x7f933344 in strlen () from /usr/lib/libc.so.1
 > > #1  0x001c4b50 in int_vasprintf (result=0xffbec6cc, 
 > format=0x1d3aa0 "Cannot resolve method %s%s%s to any 
 > overloaded instance", args=0xffbec644) at 
 > ../../libiberty/vasprintf.c:128
 > > #2  0x001c4c98 in vasprintf (result=0xffbec6cc, 
 > format=0x1d3aa0 "Cannot resolve method %s%s%s to any 
 > overloaded instance", args=0xffbec808) at 
 > ../../libiberty/vasprintf.c:158
 > > #3  0x000dcfa8 in xvasprintf (ret=0xffbec6cc, 
 > format=0x1d3aa0 "Cannot resolve method %s%s%s to any 
 > overloaded instance", ap=0xffbec808) at ../../gdb/utils.c:1191
 > > #4  0x000de220 in vfprintf_unfiltered (stream=0x6ce1a0, 
 > format=0x1d3aa0 "Cannot resolve method %s%s%s to any 
 > overloaded instance", args=0xffbec808) at ../../gdb/utils.c:2148
 > > #5  0x000dc74c in verror (string=0x1d3aa0 "Cannot resolve 
 > method %s%s%s to any overloaded instance", args=0xffbec808) 
 > at ../../gdb/utils.c:612
 > > #6  0x000dc778 in error (string=0x1d3aa0 "Cannot resolve 
 > method %s%s%s to any overloaded instance") at ../../gdb/utils.c:621
 > 
 > That call comes from valops.c:find_overload_match.  It would 
 > be nice to
 > figure out which of its arguments to error is corrupted...
 > 
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer
 > 
 
 
 ----- End forwarded message -----
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]