This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
RE: c++/1069: Issues printing derived objects with gdb
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 3 Mar 2003 20:08:01 -0000
- Subject: RE: c++/1069: Issues printing derived objects with gdb
- Reply-to: Daniel Jacobowitz <drow at mvista dot com>
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