* Crashes when "balloons" enabled @ 2008-04-01 17:55 gds 2008-04-01 18:00 ` Keith Seitz 0 siblings, 1 reply; 18+ messages in thread From: gds @ 2008-04-01 17:55 UTC (permalink / raw) To: insight I have tried 6.5 to 6.8 and they all seem to crash after accessing a balloon for me. When I allow a balloon to pop-up the program crashes (disappears) typically after re-sourcing gdbinit in the terminal (i.e., so gdbinit), not immediately. Although I have rarely seen it crash when the mouse was over a cursor and a balloon was about to pop-up. I saw this bug listed on a bug list on the insight site I think. No resolution was mentioned. Is there a possible work-around for this? I have tried various preference setting and I have found nothing that prevents a crash (except disabling the very useful balloon feature). I am building directly from source on fedora 8 and am currently using insight 6.6 since my rtos (rtems) includes gdb 6.6. Applying the rtems patches to gdb in insight has no effect on the crash. My target is arm. I am doing remote debugging to a gdb server in a ethernet connected Macraigor mpDemon. Thanks, -gene ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-01 17:55 Crashes when "balloons" enabled gds @ 2008-04-01 18:00 ` Keith Seitz 2008-04-01 18:48 ` gds ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Keith Seitz @ 2008-04-01 18:00 UTC (permalink / raw) To: gds; +Cc: insight gds wrote: > Is there a possible work-around for this? Can you give me a testcase and procedure (hopefully native linux)? The simple test case I've tried here works. Can you run insight on gdb and get a backtrace of where the thing crashes? That would be very helpful. Keith ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-01 18:00 ` Keith Seitz @ 2008-04-01 18:48 ` gds 2008-04-02 0:02 ` Doug Graham 2008-04-01 22:12 ` gds 2008-04-02 17:16 ` gds 2 siblings, 1 reply; 18+ messages in thread From: gds @ 2008-04-01 18:48 UTC (permalink / raw) To: insight [-- Attachment #1: Type: text/plain, Size: 633 bytes --] Keith Seitz wrote: > gds wrote: > >> Is there a possible work-around for this? > > Can you give me a testcase and procedure (hopefully native linux)? The > simple test case I've tried here works. > > Can you run insight on gdb and get a backtrace of where the thing > crashes? That would be very helpful. > > Keith > Attached is backtrace. Does not fail while accessing a balloon variable or during "so gdbinit" command but on first step after "so gdbinit" after having accessed balloon vars. Not sure that I can use it on native linux since compiled for arm. Do I need to reconfig/rebuild for native i386 linux? -gene [-- Attachment #2: bt.txt --] [-- Type: text/plain, Size: 11142 bytes --] [gene@aph1v93kc1nb hello_world_c]$ gdb arm-rtems4.8-insight GNU gdb Red Hat Linux (6.6-45.fc8rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) c The program is not being run. (gdb) run Starting program: /opt/rtems-4.8/bin/arm-rtems4.8-insight Program received signal SIGSEGV, Segmentation fault. check_typedef (type=0xa4892a4) at ../../insight_sources/gdb/gdbtypes.c:1384 1384 while (TYPE_CODE (type) == TYPE_CODE_TYPEDEF) Missing separate debuginfos, use: debuginfo-install expat.i386 glibc.i686 libX11.i386 libXau.i386 libXcursor.i386 libXdmcp.i386 libXfixes.i386 libXren der.i386 libxcb.i386 ncurses.i386 (gdb) bt #0 check_typedef (type=0xa4892a4) at ../../insight_sources/gdb/gdbtypes.c:1384 #1 0x080b4b63 in allocate_value (type=0xa4892a4) at ../../insight_sources/gdb/value.c:217 #2 0x080baa12 in value_zero (type=0xa4892a4, lv=not_lval) at ../../insight_sources/gdb/valops.c:465 #3 0x08147161 in varobj_get_type (var=0xa509520) at ../../insight_sources/gdb/varobj.c:756 #4 0x0814863c in varobj_update (varp=0xbfe5b898, changelist=0xbfe5b890) at ../../insight_sources/gdb/varobj.c:1634 #5 0x0808f00b in variable_obj_command (clientData=0x0, interp=0x9f38de0, objc=2, objv=0x9f3aa54) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-varobj.c:450 #6 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=2, objv=0x9f3aa54, command=0x0, length=0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #7 0x08312050 in TclExecuteByteCode (interp=0x9f38de0, codePtr=0xa284a90) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1431 #8 0x0831581d in TclCompEvalObj (interp=0x9f38de0, objPtr=0xa2dd2a0) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1008 #9 0x082ea9a9 in Tcl_EvalObjEx (interp=0x9f38de0, objPtr=0xa2dd2a0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3944 #10 0x08239a64 in Itcl_EvalMemberCode (interp=0x9f38de0, mfunc=0xa2ded90, member=0xa2deda8, contextObj=0xa2cef08, objc=1, objv=0xbfe5c480) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_methods.c:1003 #11 0x0823a9ad in Itcl_ExecMethod (clientData=0xa2ded90, interp=0x9f38de0, objc=1, objv=0xbfe5c480) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_methods.c:1516 #12 0x08240805 in Itcl_EvalArgs (interp=0x9f38de0, objc=1, objv=0xbfe5c480) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_util.c:1347 #13 0x0823bd1c in Itcl_HandleInstance (clientData=0xa2cef08, interp=0x9f38de0, objc=2, objv=0xbfe5c47c) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_objects.c:685 #14 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=2, objv=0xbfe5c47c, command=0xa465870 "::.srcwin0.srcwin.container.pane2.childsite.con updateBalloon", length=61, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #15 0x082e9eaf in Tcl_EvalEx (interp=0x9f38de0, script=0xa465870 "::.srcwin0.srcwin.container.pane2.childsite.con updateBalloon", numBytes=61, flags=262144) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3646 #16 0x082eaaae in Tcl_EvalObjEx (interp=0x9f38de0, objPtr=0xa4459b8, flags=262144) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3932 #17 0x0833de22 in Tcl_UplevelObjCmd (dummy=0x0, interp=0x9f38de0, objc=<value optimized out>, objv=<value optimized out>) at ../../../insight_sources/tcl/unix/../generic/tclProc.c:684 #18 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=4, objv=0x9f3aa44, command=0x0, length=0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #19 0x08312050 in TclExecuteByteCode (interp=0x9f38de0, codePtr=0xa0a66d8) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1431 #20 0x0831581d in TclCompEvalObj (interp=0x9f38de0, objPtr=0x9fd2910) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1008 #21 0x0833d6ed in TclObjInterpProc (clientData=0xa05d608, interp=0x9f38de0, objc=2, objv=0x9f3aa3c) at ../../../insight_sources/tcl/unix/../generic/tclProc.c:1082 #22 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=2, objv=0x9f3aa3c, command=0x0, length=0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 ---Type <return> to continue, or q <return> to quit--- #23 0x08312050 in TclExecuteByteCode (interp=0x9f38de0, codePtr=0xa14c058) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1431 #24 0x0831581d in TclCompEvalObj (interp=0x9f38de0, objPtr=0xa0a9088) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1008 #25 0x0833d6ed in TclObjInterpProc (clientData=0x9f5d7a0, interp=0x9f38de0, objc=1, objv=0x9f3aa38) at ../../../insight_sources/tcl/unix/../generic/tclProc.c:1082 #26 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=1, objv=0x9f3aa38, command=0x0, length=0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #27 0x08312050 in TclExecuteByteCode (interp=0x9f38de0, codePtr=0xa0b5cf8) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1431 #28 0x0831581d in TclCompEvalObj (interp=0x9f38de0, objPtr=0xa0b5c08) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1008 #29 0x0833d6ed in TclObjInterpProc (clientData=0xa0d7de8, interp=0x9f38de0, objc=1, objv=0xbfe5db6c) at ../../../insight_sources/tcl/unix/../generic/tclProc.c:1082 #30 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=1, objv=0xbfe5db6c, command=0x8373409 "gdbtk_tcl_idle", length=14, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #31 0x082e9eaf in Tcl_EvalEx (interp=0x9f38de0, script=0x8373409 "gdbtk_tcl_idle", numBytes=14, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3646 #32 0x082ea1ec in Tcl_Eval (interp=0x9f38de0, string=0x8373409 "gdbtk_tcl_idle") at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3811 #33 0x0808cf9c in gdbtk_call_command (cmdblk=0x9f19670, arg=0x0, from_tty=1) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-hooks.c:542 #34 0x08056dd9 in execute_command (p=0xa4b8ec9 "", from_tty=1) at ../../insight_sources/gdb/top.c:453 #35 0x0808be28 in gdb_immediate_command (clientData=0x808bd80, interp=0x9f38de0, objc=3, objv=0x9f3aa2c) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-cmds.c:749 #36 0x08087da6 in wrapped_call (opaque_args=0xbfe5dd04) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-cmds.c:420 #37 0x080e8823 in catch_errors (func=0x8087d80 <wrapped_call>, func_args=0xbfe5dd04, errstring=0x8367830 "", mask=6) at ../../insight_sources/gdb/exceptions.c:515 #38 0x08087fcc in gdbtk_call_wrapper (clientData=0x808bd80, interp=0x9f38de0, objc=3, objv=0x9f3aa2c) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-cmds.c:351 #39 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=3, objv=0x9f3aa2c, command=0x0, length=0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #40 0x08312050 in TclExecuteByteCode (interp=0x9f38de0, codePtr=0xa35c530) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1431 #41 0x0831581d in TclCompEvalObj (interp=0x9f38de0, objPtr=0xa14ca40) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1008 #42 0x082ea9a9 in Tcl_EvalObjEx (interp=0x9f38de0, objPtr=0xa14ca40, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3944 #43 0x08239a64 in Itcl_EvalMemberCode (interp=0x9f38de0, mfunc=0xa153568, member=0xa153488, contextObj=0x9fd4550, objc=1, objv=0xbfe5e900) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_methods.c:1003 #44 0x0823a9ad in Itcl_ExecMethod (clientData=0xa153568, interp=0x9f38de0, objc=1, objv=0xbfe5e900) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_methods.c:1516 #45 0x08240805 in Itcl_EvalArgs (interp=0x9f38de0, objc=1, objv=0xbfe5e900) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_util.c:1347 #46 0x0823bd1c in Itcl_HandleInstance (clientData=0x9fd4550, interp=0x9f38de0, objc=2, objv=0xbfe5e8fc) ---Type <return> to continue, or q <return> to quit--- at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_objects.c:685 #47 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=2, objv=0xbfe5e8fc, command=0xa507cf0 "::.console0.console invoke; break", length=27, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #48 0x082e9eaf in Tcl_EvalEx (interp=0x9f38de0, script=0xa507cf0 "::.console0.console invoke; break", numBytes=33, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3646 #49 0x082ea1ec in Tcl_Eval (interp=0x9f38de0, string=0xa507cf0 "::.console0.console invoke; break") at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3811 #50 0x082ea286 in Tcl_GlobalEval (interp=0x9f38de0, command=0xa507cf0 "::.console0.console invoke; break") at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:5261 #51 0x082ce6f7 in Tk_BindEvent (bindingTable=0x9f622e0, eventPtr=0xa5122f0, tkwin=0xa186f88, numObjects=0, objectPtr=0xbfe5ed7c) at /home/gene/4.8.0-rtems/archive/insight_sources/tk/unix/../generic/tkBind.c:1805 #52 0x082d2784 in TkBindEventProc (winPtr=0xa186f88, eventPtr=0xa5122f0) at /home/gene/4.8.0-rtems/archive/insight_sources/tk/unix/../generic/tkCmds.c:287 #53 0x0824f3bd in Tk_HandleEvent (eventPtr=0xa5122f0) at /home/gene/4.8.0-rtems/archive/insight_sources/tk/unix/../generic/tkEvent.c:1017 #54 0x0824f9a2 in WindowEventProc (evPtr=0xa5122e8, flags=<value optimized out>) at /home/gene/4.8.0-rtems/archive/insight_sources/tk/unix/../generic/tkEvent.c:1399 #55 0x083339c0 in Tcl_ServiceEvent (flags=-3) at ../../../insight_sources/tcl/unix/../generic/tclNotify.c:622 #56 0x08333c67 in Tcl_DoOneEvent (flags=-3) at ../../../insight_sources/tcl/unix/../generic/tclNotify.c:861 #57 0x0824e990 in Tk_MainLoop () at /home/gene/4.8.0-rtems/archive/insight_sources/tk/unix/../generic/tkEvent.c:1457 #58 0x0805024b in captured_command_loop (data=0x0) at ../../insight_sources/gdb/main.c:101 #59 0x080e8823 in catch_errors (func=0x8050240 <captured_command_loop>, func_args=0x0, errstring=0x8367830 "", mask=6) at ../../insight_sources/gdb/exceptions.c:515 #60 0x080509e4 in captured_main (data=0xbfe5f0b4) at ../../insight_sources/gdb/main.c:826 #61 0x080e8823 in catch_errors (func=0x8050280 <captured_main>, func_args=0xbfe5f0b4, errstring=0x8367830 "", mask=6) at ../../insight_sources/gdb/exceptions.c:515 #62 0x08050231 in gdb_main (args=0xbfe5f0b4) at ../../insight_sources/gdb/main.c:835 #63 0x080501f5 in main (argc=Cannot access memory at address 0x1c ) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-main.c:36 (gdb) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-01 18:48 ` gds @ 2008-04-02 0:02 ` Doug Graham 2008-04-02 14:00 ` gds 2008-04-02 15:52 ` gds 0 siblings, 2 replies; 18+ messages in thread From: Doug Graham @ 2008-04-02 0:02 UTC (permalink / raw) To: gds; +Cc: insight Not sure whether this helps or not as it probably doesn't fix the root cause, but I ran into this same problem some time ago and "fixed" it with the following patch (from Insight 6.5): *** varobj.c 2006/12/03 17:07:37 1.1 --- varobj.c 2006/12/03 17:08:49 *************** *** 1761,1766 **** --- 1761,1773 ---- target = get_target_type (type); children = 0; + /* + * [++doug] Saw crash here with var->type==NULL. So check for + * that before calling TYPE_CODE on it. + */ + if (type == NULL) + return children; + switch (TYPE_CODE (type)) { case TYPE_CODE_ARRAY: *************** *** 1828,1833 **** --- 1835,1848 ---- type = get_type (parent); target = get_target_type (type); + /* + * [++doug] Haven't actually run into a NULL type here yet, but we + * have in a couple of the other c_* routines, so lets be defensive + * here. + */ + if (type == NULL) + return (xstrdup("<?null_type?>")); + switch (TYPE_CODE (type)) { case TYPE_CODE_ARRAY: *************** *** 1938,1944 **** temp = parent->value; value = NULL; ! if (temp != NULL) { switch (TYPE_CODE (type)) { --- 1953,1964 ---- temp = parent->value; value = NULL; ! /* ! * [++doug] Haven't actually run into a NULL type here yet, but we ! * have in a couple of the other c_* routines, so lets be defensive ! * here. ! */ ! if (temp != NULL && type != NULL) { switch (TYPE_CODE (type)) { *************** *** 2034,2040 **** static int c_variable_editable (struct varobj *var) { ! switch (TYPE_CODE (get_type (var))) { case TYPE_CODE_STRUCT: case TYPE_CODE_UNION: --- 2054,2069 ---- static int c_variable_editable (struct varobj *var) { ! /* ! * [++doug] Haven't actually run into a NULL type here yet, but we ! * have in a couple of the other c_* routines, so lets be defensive ! * here. ! */ ! struct type *type = get_type(var); ! if (type == NULL) ! return 0; ! ! switch (TYPE_CODE (type)) { case TYPE_CODE_STRUCT: case TYPE_CODE_UNION: *************** *** 2059,2064 **** --- 2088,2107 ---- catch that case explicitly. */ struct type *type = get_type (var); + /* + * [++doug] Saw crash here with var->type==NULL. So check for + * that before calling TYPE_CODE on it. var was: + * + * (gdb) p *var + * $4 = {name = 0xa70dc90 "item", obj_name = 0xa70de40 "var77.code.item", + * index = 0, type = 0x0, + * value = 0x0, error = 0, num_children = -1, parent = 0x86e2fd0, children = 0x0, + * root = 0xa5768e0, format = FORMAT_NATURAL, updated = 0} + * + */ + if (type == NULL) + return xstrdup("<?null_type?>"); + /* Strip top-level references. */ while (TYPE_CODE (type) == TYPE_CODE_REF) type = check_typedef (TYPE_TARGET_TYPE (type)); --Doug. -----Original Message----- To: insight@sources.redhat.com From: gds <gds@chartertn.net> Subject: Re: Crashes when "balloons" enabled Date: Tue, 01 Apr 2008 14:47:50 -0400 Keith Seitz wrote: >gds wrote: > >>Is there a possible work-around for this? > >Can you give me a testcase and procedure (hopefully native linux)? The >simple test case I've tried here works. > >Can you run insight on gdb and get a backtrace of where the thing >crashes? That would be very helpful. > >Keith > Attached is backtrace. Does not fail while accessing a balloon variable or during "so gdbinit" command but on first step after "so gdbinit" after having accessed balloon vars. Not sure that I can use it on native linux since compiled for arm. Do I need to reconfig/rebuild for native i386 linux? -gene [gene@aph1v93kc1nb hello_world_c]$ gdb arm-rtems4.8-insight GNU gdb Red Hat Linux (6.6-45.fc8rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) c The program is not being run. (gdb) run Starting program: /opt/rtems-4.8/bin/arm-rtems4.8-insight Program received signal SIGSEGV, Segmentation fault. check_typedef (type=0xa4892a4) at ../../insight_sources/gdb/gdbtypes.c:1384 1384 while (TYPE_CODE (type) == TYPE_CODE_TYPEDEF) Missing separate debuginfos, use: debuginfo-install expat.i386 glibc.i686 libX11.i386 libXau.i386 libXcursor.i386 libXdmcp.i386 libXfixes.i386 libXren der.i386 libxcb.i386 ncurses.i386 (gdb) bt #0 check_typedef (type=0xa4892a4) at ../../insight_sources/gdb/gdbtypes.c:1384 #1 0x080b4b63 in allocate_value (type=0xa4892a4) at ../../insight_sources/gdb/value.c:217 #2 0x080baa12 in value_zero (type=0xa4892a4, lv=not_lval) at ../../insight_sources/gdb/valops.c:465 #3 0x08147161 in varobj_get_type (var=0xa509520) at ../../insight_sources/gdb/varobj.c:756 #4 0x0814863c in varobj_update (varp=0xbfe5b898, changelist=0xbfe5b890) at ../../insight_sources/gdb/varobj.c:1634 #5 0x0808f00b in variable_obj_command (clientData=0x0, interp=0x9f38de0, objc=2, objv=0x9f3aa54) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-varobj.c:450 #6 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=2, objv=0x9f3aa54, command=0x0, length=0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #7 0x08312050 in TclExecuteByteCode (interp=0x9f38de0, codePtr=0xa284a90) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1431 #8 0x0831581d in TclCompEvalObj (interp=0x9f38de0, objPtr=0xa2dd2a0) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1008 #9 0x082ea9a9 in Tcl_EvalObjEx (interp=0x9f38de0, objPtr=0xa2dd2a0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3944 #10 0x08239a64 in Itcl_EvalMemberCode (interp=0x9f38de0, mfunc=0xa2ded90, member=0xa2deda8, contextObj=0xa2cef08, objc=1, objv=0xbfe5c480) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_methods.c:1003 #11 0x0823a9ad in Itcl_ExecMethod (clientData=0xa2ded90, interp=0x9f38de0, objc=1, objv=0xbfe5c480) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_methods.c:1516 #12 0x08240805 in Itcl_EvalArgs (interp=0x9f38de0, objc=1, objv=0xbfe5c480) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_util.c:1347 #13 0x0823bd1c in Itcl_HandleInstance (clientData=0xa2cef08, interp=0x9f38de0, objc=2, objv=0xbfe5c47c) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_objects.c:685 #14 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=2, objv=0xbfe5c47c, command=0xa465870 "::.srcwin0.srcwin.container.pane2.childsite.con updateBalloon", length=61, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #15 0x082e9eaf in Tcl_EvalEx (interp=0x9f38de0, script=0xa465870 "::.srcwin0.srcwin.container.pane2.childsite.con updateBalloon", numBytes=61, flags=262144) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3646 #16 0x082eaaae in Tcl_EvalObjEx (interp=0x9f38de0, objPtr=0xa4459b8, flags=262144) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3932 #17 0x0833de22 in Tcl_UplevelObjCmd (dummy=0x0, interp=0x9f38de0, objc=<value optimized out>, objv=<value optimized out>) at ../../../insight_sources/tcl/unix/../generic/tclProc.c:684 #18 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=4, objv=0x9f3aa44, command=0x0, length=0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #19 0x08312050 in TclExecuteByteCode (interp=0x9f38de0, codePtr=0xa0a66d8) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1431 #20 0x0831581d in TclCompEvalObj (interp=0x9f38de0, objPtr=0x9fd2910) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1008 #21 0x0833d6ed in TclObjInterpProc (clientData=0xa05d608, interp=0x9f38de0, objc=2, objv=0x9f3aa3c) at ../../../insight_sources/tcl/unix/../generic/tclProc.c:1082 #22 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=2, objv=0x9f3aa3c, command=0x0, length=0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 ---Type <return> to continue, or q <return> to quit--- #23 0x08312050 in TclExecuteByteCode (interp=0x9f38de0, codePtr=0xa14c058) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1431 #24 0x0831581d in TclCompEvalObj (interp=0x9f38de0, objPtr=0xa0a9088) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1008 #25 0x0833d6ed in TclObjInterpProc (clientData=0x9f5d7a0, interp=0x9f38de0, objc=1, objv=0x9f3aa38) at ../../../insight_sources/tcl/unix/../generic/tclProc.c:1082 #26 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=1, objv=0x9f3aa38, command=0x0, length=0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #27 0x08312050 in TclExecuteByteCode (interp=0x9f38de0, codePtr=0xa0b5cf8) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1431 #28 0x0831581d in TclCompEvalObj (interp=0x9f38de0, objPtr=0xa0b5c08) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1008 #29 0x0833d6ed in TclObjInterpProc (clientData=0xa0d7de8, interp=0x9f38de0, objc=1, objv=0xbfe5db6c) at ../../../insight_sources/tcl/unix/../generic/tclProc.c:1082 #30 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=1, objv=0xbfe5db6c, command=0x8373409 "gdbtk_tcl_idle", length=14, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #31 0x082e9eaf in Tcl_EvalEx (interp=0x9f38de0, script=0x8373409 "gdbtk_tcl_idle", numBytes=14, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3646 #32 0x082ea1ec in Tcl_Eval (interp=0x9f38de0, string=0x8373409 "gdbtk_tcl_idle") at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3811 #33 0x0808cf9c in gdbtk_call_command (cmdblk=0x9f19670, arg=0x0, from_tty=1) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-hooks.c:542 #34 0x08056dd9 in execute_command (p=0xa4b8ec9 "", from_tty=1) at ../../insight_sources/gdb/top.c:453 #35 0x0808be28 in gdb_immediate_command (clientData=0x808bd80, interp=0x9f38de0, objc=3, objv=0x9f3aa2c) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-cmds.c:749 #36 0x08087da6 in wrapped_call (opaque_args=0xbfe5dd04) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-cmds.c:420 #37 0x080e8823 in catch_errors (func=0x8087d80 <wrapped_call>, func_args=0xbfe5dd04, errstring=0x8367830 "", mask=6) at ../../insight_sources/gdb/exceptions.c:515 #38 0x08087fcc in gdbtk_call_wrapper (clientData=0x808bd80, interp=0x9f38de0, objc=3, objv=0x9f3aa2c) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-cmds.c:351 #39 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=3, objv=0x9f3aa2c, command=0x0, length=0, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #40 0x08312050 in TclExecuteByteCode (interp=0x9f38de0, codePtr=0xa35c530) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1431 #41 0x0831581d in TclCompEvalObj (interp=0x9f38de0, objPtr=0xa14ca40) at ../../../insight_sources/tcl/unix/../generic/tclExecute.c:1008 #42 0x082ea9a9 in Tcl_EvalObjEx (interp=0x9f38de0, objPtr=0xa14ca40, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3944 #43 0x08239a64 in Itcl_EvalMemberCode (interp=0x9f38de0, mfunc=0xa153568, member=0xa153488, contextObj=0x9fd4550, objc=1, objv=0xbfe5e900) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_methods.c:1003 #44 0x0823a9ad in Itcl_ExecMethod (clientData=0xa153568, interp=0x9f38de0, objc=1, objv=0xbfe5e900) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_methods.c:1516 #45 0x08240805 in Itcl_EvalArgs (interp=0x9f38de0, objc=1, objv=0xbfe5e900) at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_util.c:1347 #46 0x0823bd1c in Itcl_HandleInstance (clientData=0x9fd4550, interp=0x9f38de0, objc=2, objv=0xbfe5e8fc) ---Type <return> to continue, or q <return> to quit--- at /home/gene/4.8.0-rtems/archive/insight_sources/itcl/itcl/generic/itcl_objects.c:685 #47 0x082e98e1 in TclEvalObjvInternal (interp=0x9f38de0, objc=2, objv=0xbfe5e8fc, command=0xa507cf0 "::.console0.console invoke; break", length=27, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3048 #48 0x082e9eaf in Tcl_EvalEx (interp=0x9f38de0, script=0xa507cf0 "::.console0.console invoke; break", numBytes=33, flags=0) at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3646 #49 0x082ea1ec in Tcl_Eval (interp=0x9f38de0, string=0xa507cf0 "::.console0.console invoke; break") at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:3811 #50 0x082ea286 in Tcl_GlobalEval (interp=0x9f38de0, command=0xa507cf0 "::.console0.console invoke; break") at ../../../insight_sources/tcl/unix/../generic/tclBasic.c:5261 #51 0x082ce6f7 in Tk_BindEvent (bindingTable=0x9f622e0, eventPtr=0xa5122f0, tkwin=0xa186f88, numObjects=0, objectPtr=0xbfe5ed7c) at /home/gene/4.8.0-rtems/archive/insight_sources/tk/unix/../generic/tkBind.c:1805 #52 0x082d2784 in TkBindEventProc (winPtr=0xa186f88, eventPtr=0xa5122f0) at /home/gene/4.8.0-rtems/archive/insight_sources/tk/unix/../generic/tkCmds.c:287 #53 0x0824f3bd in Tk_HandleEvent (eventPtr=0xa5122f0) at /home/gene/4.8.0-rtems/archive/insight_sources/tk/unix/../generic/tkEvent.c:1017 #54 0x0824f9a2 in WindowEventProc (evPtr=0xa5122e8, flags=<value optimized out>) at /home/gene/4.8.0-rtems/archive/insight_sources/tk/unix/../generic/tkEvent.c:1399 #55 0x083339c0 in Tcl_ServiceEvent (flags=-3) at ../../../insight_sources/tcl/unix/../generic/tclNotify.c:622 #56 0x08333c67 in Tcl_DoOneEvent (flags=-3) at ../../../insight_sources/tcl/unix/../generic/tclNotify.c:861 #57 0x0824e990 in Tk_MainLoop () at /home/gene/4.8.0-rtems/archive/insight_sources/tk/unix/../generic/tkEvent.c:1457 #58 0x0805024b in captured_command_loop (data=0x0) at ../../insight_sources/gdb/main.c:101 #59 0x080e8823 in catch_errors (func=0x8050240 <captured_command_loop>, func_args=0x0, errstring=0x8367830 "", mask=6) at ../../insight_sources/gdb/exceptions.c:515 #60 0x080509e4 in captured_main (data=0xbfe5f0b4) at ../../insight_sources/gdb/main.c:826 #61 0x080e8823 in catch_errors (func=0x8050280 <captured_main>, func_args=0xbfe5f0b4, errstring=0x8367830 "", mask=6) at ../../insight_sources/gdb/exceptions.c:515 #62 0x08050231 in gdb_main (args=0xbfe5f0b4) at ../../insight_sources/gdb/main.c:835 #63 0x080501f5 in main (argc=Cannot access memory at address 0x1c ) at ../../insight_sources/gdb/gdbtk/generic/gdbtk-main.c:36 (gdb) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-02 0:02 ` Doug Graham @ 2008-04-02 14:00 ` gds 2008-04-02 15:52 ` gds 1 sibling, 0 replies; 18+ messages in thread From: gds @ 2008-04-02 14:00 UTC (permalink / raw) To: insight Doug Graham wrote: > Not sure whether this helps or not as it probably doesn't fix the root > cause, but I ran into this same problem some time ago and "fixed" it > with the following patch (from Insight 6.5): Applied patch. Think it helped. Was able to do "so gdbinit" once after inspecting variables in balloons but crashed the second time. Will try a similar null check at the point where mine is crashing. Thanks. -gene ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-02 0:02 ` Doug Graham 2008-04-02 14:00 ` gds @ 2008-04-02 15:52 ` gds 2008-04-02 17:14 ` Doug Graham 2008-04-02 17:23 ` Keith Seitz 1 sibling, 2 replies; 18+ messages in thread From: gds @ 2008-04-02 15:52 UTC (permalink / raw) To: insight Doug, I found this patch from your previous thread "Unwinding TCL Stack" and applied it to 6.6. Unfortunately it seems to just disable the balloon effects entirely, for me. These type of problems might be why Macraigor only supports gdb in Eclipse now (just on windows). They told me Insight has problems (paraphrasing!) but I didn't believe them since I used it several years ago with PPC with their debugger with absolutely no problems. Not sure what version I used (it was under cygwin and probably <6.4. (Could not get insight 6.4 to build due to something about makeinfo.) I will poke around a bit more. Any suggestions or help is appreciated. -gene diff -c -r1.1 ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c *** ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c 2007/07/14 18:33:59 1.1 --- ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c 2007/07/14 18:34:03 *************** *** 599,606 **** static void install_variable (Tcl_Interp *interp, char *name) { ! Tcl_CreateObjCommand (interp, name, variable_obj_command, ! NULL, NULL); } --- 599,606 ---- static void install_variable (Tcl_Interp *interp, char *name) { ! Tcl_CreateObjCommand (interp, name, gdbtk_call_wrapper, ! (ClientData) variable_obj_command, NULL); } ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-02 15:52 ` gds @ 2008-04-02 17:14 ` Doug Graham 2008-04-02 17:23 ` Keith Seitz 1 sibling, 0 replies; 18+ messages in thread From: Doug Graham @ 2008-04-02 17:14 UTC (permalink / raw) To: gds; +Cc: insight I never actually deployed the patch you include below because I didn't hear back from the list telling me it was the right thing to do, and because I wasn't confident that I understood this code well enough to be making changes like this. The problem it was solving didn't occur often enough to be a serious PITA anyway. But I did do some testing with it, and I'm sure I would have noticed if it had made balloons disappear entirely. I don't know why it's doing that for you. In any case, I doubt that this patch addresses your immediate problem. I've since moved on to other things and don't use Insight much any more, so I don't think I can offer any other suggestions. I've just looked over all the patches that I applied to 6.5, and the only other one that looks like it might be important (but unrelated to your crash) is a fix for a buffer overrun in the C++ demangler: *** cplus-dem.c 2006/08/17 19:09:27 1.1 --- cplus-dem.c 2006/08/17 19:09:29 *************** *** 3693,3699 **** --- 3693,3711 ---- { int done = 0; int success = 1; + #if 0 char buf[INTBUF_SIZE + 5 /* 'int%u_t' */]; + #else + /* + * I think the demangler is totally misbehaving to cause this, but it does + * a sprintf (buf, "int%u_t", dec) below, where "dec" apparently contains + * junk. That was overrunning buf, so let's make it a bit bigger. Need to + * revisit this demangling stuff someday, because the demangler is definitely + * not doing the right thing (it's interpreting variable names as if they were + * special type characters). + */ + char buf[16]; + #endif unsigned int dec = 0; type_kind_t tk = tk_integral; *************** *** 3834,3839 **** --- 3846,3852 ---- buf[2] = '\0'; *mangled += min (strlen (*mangled), 2); } + dec = 0; /* In case the sscanf fails */ sscanf (buf, "%x", &dec); sprintf (buf, "int%u_t", dec); APPEND_BLANK (result); --Doug. -----Original Message----- To: insight@sources.redhat.com From: gds <gds@chartertn.net> Subject: Re: Crashes when "balloons" enabled Date: Wed, 02 Apr 2008 11:51:27 -0400 Doug, I found this patch from your previous thread "Unwinding TCL Stack" and applied it to 6.6. Unfortunately it seems to just disable the balloon effects entirely, for me. These type of problems might be why Macraigor only supports gdb in Eclipse now (just on windows). They told me Insight has problems (paraphrasing!) but I didn't believe them since I used it several years ago with PPC with their debugger with absolutely no problems. Not sure what version I used (it was under cygwin and probably <6.4. (Could not get insight 6.4 to build due to something about makeinfo.) I will poke around a bit more. Any suggestions or help is appreciated. -gene diff -c -r1.1 ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c *** ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c 2007/07/14 18:33:59 1.1 --- ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c 2007/07/14 18:34:03 *************** *** 599,606 **** static void install_variable (Tcl_Interp *interp, char *name) { ! Tcl_CreateObjCommand (interp, name, variable_obj_command, ! NULL, NULL); } --- 599,606 ---- static void install_variable (Tcl_Interp *interp, char *name) { ! Tcl_CreateObjCommand (interp, name, gdbtk_call_wrapper, ! (ClientData) variable_obj_command, NULL); } ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-02 15:52 ` gds 2008-04-02 17:14 ` Doug Graham @ 2008-04-02 17:23 ` Keith Seitz 2008-04-02 17:44 ` Doug Graham 2008-04-02 18:19 ` gds 1 sibling, 2 replies; 18+ messages in thread From: Keith Seitz @ 2008-04-02 17:23 UTC (permalink / raw) To: gds; +Cc: insight gds wrote: > They told me Insight has problems (paraphrasing!) I find that very amusing. I'm actually glad that they stop recommending people use insight: I'm tired of being their support forum. > diff -c -r1.1 ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c > *** ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c 2007/07/14 > 18:33:59 1.1 > --- ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c 2007/07/14 18:34:03 > *************** > *** 599,606 **** > static void > install_variable (Tcl_Interp *interp, char *name) > { > ! Tcl_CreateObjCommand (interp, name, variable_obj_command, > ! NULL, NULL); > } > --- 599,606 ---- > static void > install_variable (Tcl_Interp *interp, char *name) > { > ! Tcl_CreateObjCommand (interp, name, gdbtk_call_wrapper, > ! (ClientData) variable_obj_command, NULL); > } > This patch should not be necessary: varobj should NEVER longjmp. It was designed that way. BTW, all those other patches are against GDB, not insight. I'm afraid I still don't understand what your procedure for producing this bug is. Can you restate it, AND BE CONCISE. (ie., 1. Load this, 2. click this, 3. click that). The more detail you give me, the better off I'll be when I attempt to reproduce this here. My guess is you've tickled a bug in GDB's varobj system. But it could be an unknown bug with insight (like not erasing varobjs when needed). Keith ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-02 17:23 ` Keith Seitz @ 2008-04-02 17:44 ` Doug Graham 2008-04-02 18:01 ` Keith Seitz 2008-04-02 18:19 ` gds 1 sibling, 1 reply; 18+ messages in thread From: Doug Graham @ 2008-04-02 17:44 UTC (permalink / raw) To: Keith Seitz; +Cc: gds, insight I don't want to hijack this thread, but I am curious about how the varobj stuff is never supposed to longjmp. I included a backtrace in that bug report that showed where the longjmp was occurring from in my case, and it makes sense to me. I can't see how it could be possible that the value of a variable be displayed without attempting to read it from target memory, and I think that all reads from target memory can throw exceptions. Here's where I encountered the throw (copied from http://sourceware.org/ml/insight/2007-q3/msg00009.html): #0 throw_exception (exception= {reason = RETURN_ERROR, error = GENERIC_ERROR, message = 0x97e9478 "Cannot access memory at address 0xffffff45"}) at ../../insight-6.5/gdb/exceptions.c:222 #1 0x08122ae8 in throw_it (reason=Variable "reason" is not available. ) at ../../insight-6.5/gdb/exceptions.c:410 #2 0x08122b01 in throw_verror (error=GDB_NO_ERROR, fmt=Could not find the frame base for "throw_verror". ) at ../../insight-6.5/gdb/exceptions.c:416 #3 0x0809927c in error (string=Could not find the frame base for "error". ) at ../../insight-6.5/gdb/utils.c:649 #4 0x0809b1af in error_stream (stream=Could not find the frame base for "error_stream". ) at ../../insight-6.5/gdb/utils.c:678 #5 0x0809737c in memory_error (status=5, memaddr=4294967109) at ../../insight-6.5/gdb/corefile.c:232 #6 0x080fc146 in value_fetch_lazy (val=0x97e94e8) at ../../insight-6.5/gdb/valops.c:515 #7 0x08175e79 in gdb_value_fetch_lazy (val=0x97e94e8) at ../../insight-6.5/gdb/wrapper.c:64 #8 0x0817550d in c_value_of_variable (var=0x97e9560) at ../../insight-6.5/gdb/varobj.c:2141 #9 0x080d6cef in variable_obj_command (clientData=0x0, interp=0x8459df0, objc=2, objv=0x845c0f4) at ../../insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c:580 #10 0x082cefc2 in TclEvalObjvInternal (interp=0x8459df0, objc=2, objv=0x845c0f4, command=0x0, length=0, flags=0) at ../../../insight-6.5/tcl/unix/../generic/tclBasic.c:3048 variable_obj_command() does appear in that backtrace, and it does eventually call memory_error(), which throws an exception. As I mentioned, I think this ocurrred because the stack was badly corrupted, but that's not an unusual situation. --Doug. -----Original Message----- Date: Wed, 02 Apr 2008 10:20:00 -0700 From: Keith Seitz <keiths@redhat.com> To: gds <gds@chartertn.net> CC: insight@sources.redhat.com Subject: Re: Crashes when "balloons" enabled gds wrote: >They told me Insight has problems (paraphrasing!) I find that very amusing. I'm actually glad that they stop recommending people use insight: I'm tired of being their support forum. >diff -c -r1.1 ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c >*** ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c 2007/07/14 >18:33:59 1.1 >--- ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c 2007/07/14 18:34:03 >*************** >*** 599,606 **** > static void > install_variable (Tcl_Interp *interp, char *name) > { >! Tcl_CreateObjCommand (interp, name, variable_obj_command, >! NULL, NULL); > } >--- 599,606 ---- > static void > install_variable (Tcl_Interp *interp, char *name) > { >! Tcl_CreateObjCommand (interp, name, gdbtk_call_wrapper, >! (ClientData) variable_obj_command, NULL); > } > This patch should not be necessary: varobj should NEVER longjmp. It was designed that way. BTW, all those other patches are against GDB, not insight. I'm afraid I still don't understand what your procedure for producing this bug is. Can you restate it, AND BE CONCISE. (ie., 1. Load this, 2. click this, 3. click that). The more detail you give me, the better off I'll be when I attempt to reproduce this here. My guess is you've tickled a bug in GDB's varobj system. But it could be an unknown bug with insight (like not erasing varobjs when needed). Keith ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-02 17:44 ` Doug Graham @ 2008-04-02 18:01 ` Keith Seitz 2008-04-02 20:06 ` Doug Graham 0 siblings, 1 reply; 18+ messages in thread From: Keith Seitz @ 2008-04-02 18:01 UTC (permalink / raw) To: Doug Graham; +Cc: gds, insight Doug Graham wrote: > #7 0x08175e79 in gdb_value_fetch_lazy (val=0x97e94e8) > at ../../insight-6.5/gdb/wrapper.c:64 This function is a call wrapper: it "wraps" the gdb call, value_fetch_lazy (which will longjmp) with a version which catches the exception and returns a value indicating success or failure: int gdb_value_fetch_lazy (struct value *val) { volatile struct gdb_exception except; TRY_CATCH (except, RETURN_MASK_ERROR) { value_fetch_lazy (val); } if (except.reason < 0) return 0; return 1; } So somewhere underneath this there is a disconnect about error handling, because this exception should have been caught here. I don't see anything obvious by just perusing the sources, so I'll have to dig in to see what could be happening. Keith ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-02 18:01 ` Keith Seitz @ 2008-04-02 20:06 ` Doug Graham 2008-04-02 20:12 ` Keith Seitz 0 siblings, 1 reply; 18+ messages in thread From: Doug Graham @ 2008-04-02 20:06 UTC (permalink / raw) To: Keith Seitz; +Cc: gds, insight On Wed, Apr 02, 2008 at 10:58:11AM -0700, Keith Seitz wrote: > Doug Graham wrote: > >#7 0x08175e79 in gdb_value_fetch_lazy (val=0x97e94e8) > > at ../../insight-6.5/gdb/wrapper.c:64 > > This function is a call wrapper: it "wraps" the gdb call, > value_fetch_lazy (which will longjmp) with a version which catches the > exception and returns a value indicating success or failure: Ah, ok. I didn't know that there were other places that Insight catches GDB exceptions. I think then that my problem must have been caused by what I called the "third throw" in my bug report. That one showed memory_error() being called via a backtrace that didn't include gdb_value_fetch_lazy() or anything else in wrapper.c. The 6.5 version of c_value_of_variable() does this: varobj.c:2140 if (value_lazy (var->value)) gdb_value_fetch_lazy (var->value); common_val_print (var->value, stb, format_code[(int) var->format], 1, 0, 0); gdb_value_fetch_lazy() would have caught the error and returned normally, but nothing checks the return code, and common_val_print() is called regardless. It appears that if gdb_value_fetch_lazy() didn't manage to fetch the variable's value, then common_val_print() notices that and tries again: #0 throw_exception (exception= {reason = RETURN_ERROR, error = GENERIC_ERROR, message = 0x93e0a60 "Cannot access memory at address 0xffffff45"}) at ../../insight-6.5/gdb/exceptions.c:222 #1 0x08122ae8 in throw_it (reason=Variable "reason" is not available.) at ../../insight-6.5/gdb/exceptions.c:410 #2 0x08122b01 in throw_verror (error=GDB_NO_ERROR, fmt=Could not find the frame base for "throw_verror".) at ../../insight-6.5/gdb/exceptions.c:416 #3 0x0809927c in error (string=Could not find the frame base for "error".) at ../../insight-6.5/gdb/utils.c:649 #4 0x0809b1af in error_stream (stream=Could not find the frame base for "error_stream".) at ../../insight-6.5/gdb/utils.c:678 #5 0x0809737c in memory_error (status=5, memaddr=4294967109) at ../../insight-6.5/gdb/corefile.c:232 #6 0x080fc146 in value_fetch_lazy (val=0x97e94e8) at ../../insight-6.5/gdb/valops.c:515 #7 0x080f5cf5 in value_contents_all (value=0x97e94e8) at ../../insight-6.5/gdb/value.c:331 #8 0x08102776 in common_val_print (val=0x97e94e8, stream=0x97b04b8, format=0, deref_ref=1, recurse=0, pretty=Val_no_prettyprint) at ../../insight-6.5/gdb/valprint.c:274 #9 0x08175470 in c_value_of_variable (var=0x97e9560) at ../../insight-6.5/gdb/varobj.c:2142 #10 0x080d6cef in variable_obj_command (clientData=0x0, interp=0x8459df0, objc=2, objv=0x845c0f4) But c_value_of_variable() has been rewritten in 6.8 (but not 6.7.1), and it looks like this bug might have been fixed, perhaps inadvertantly: varobj.c:2247 if (var->not_fetched && value_lazy (var->value)) /* Frozen variable and no value yet. We don't implicitly fetch the value. MI response will use empty string for the value, which is OK. */ return NULL; It doesn't call either of gdb_value_fetch_lazy() or common_val_print() any more. --Doug. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-02 20:06 ` Doug Graham @ 2008-04-02 20:12 ` Keith Seitz 0 siblings, 0 replies; 18+ messages in thread From: Keith Seitz @ 2008-04-02 20:12 UTC (permalink / raw) To: Doug Graham; +Cc: gds, insight Doug Graham wrote: > But c_value_of_variable() has been rewritten in 6.8 (but not 6.7.1), > and it looks like this bug might have been fixed, perhaps inadvertantly: > > varobj.c:2247 > if (var->not_fetched && value_lazy (var->value)) > /* Frozen variable and no value yet. We don't > implicitly fetch the value. MI response will > use empty string for the value, which is OK. */ > return NULL; > > It doesn't call either of gdb_value_fetch_lazy() or common_val_print() > any more. Yeah, there has been some churn in varobj in gdb recently. I'll have to double-check this to make sure that it is still "safe" or whether I have to jump through (even more) hoops to make it safe again. Keith ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-02 17:23 ` Keith Seitz 2008-04-02 17:44 ` Doug Graham @ 2008-04-02 18:19 ` gds 2008-04-02 18:41 ` Keith Seitz 1 sibling, 1 reply; 18+ messages in thread From: gds @ 2008-04-02 18:19 UTC (permalink / raw) To: insight Keith Seitz wrote: > gds wrote: > >> They told me Insight has problems (paraphrasing!) > > I find that very amusing. I'm actually glad that they stop recommending > people use insight: I'm tired of being their support forum. > > >> diff -c -r1.1 ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c >> *** ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c 2007/07/14 >> 18:33:59 1.1 >> --- ./insight-6.5/gdb/gdbtk/generic/gdbtk-varobj.c 2007/07/14 >> 18:34:03 >> *************** >> *** 599,606 **** >> static void >> install_variable (Tcl_Interp *interp, char *name) >> { >> ! Tcl_CreateObjCommand (interp, name, variable_obj_command, >> ! NULL, NULL); >> } >> --- 599,606 ---- >> static void >> install_variable (Tcl_Interp *interp, char *name) >> { >> ! Tcl_CreateObjCommand (interp, name, gdbtk_call_wrapper, >> ! (ClientData) variable_obj_command, NULL); >> } >> > > This patch should not be necessary: varobj should NEVER longjmp. It was > designed that way. I tried it and for me all it did was disable ballooning. So I backed it out. > > BTW, all those other patches are against GDB, not insight. I'm afraid I > still don't understand what your procedure for producing this bug is. > Can you restate it, AND BE CONCISE. (ie., 1. Load this, 2. click this, > 3. click that). The more detail you give me, the better off I'll be when > I attempt to reproduce this here. > > My guess is you've tickled a bug in GDB's varobj system. But it could be > an unknown bug with insight (like not erasing varobjs when needed). > > Keith Ok, here's the procedure. 1. Start insight from kde Konsole: $ arm-rtems4.8-insight -x ./gdbinit & 2. Click inside insight source window and hit C 3. Program runs "hello world" program and prints the usual to gtkterm console (via target serial port) ending with message "hit Any key to reboot". 4. I hit a key in gtkterm console window. 5. Program prints a "data abort" message in the gtkterm console. (This is expected.) 6. Looking back at the insight source window, the STOP button is RED so I press it. 7. Message pops up about SIGTRAP, I hit OK. 8. File abort.c appears in the source window with green bar pointing at while(1) { continue;} construct (infinite loop). This is expected. 9. With mouse I examine some local and global variables. I don't think it matters which ones. They pop up in the balloons as expected. Crash does *not* occur here while looking a vars with mouse! 10. I go to the insight console window (not gtkterm's) and type gdb cmd source gdbinit to redownload the program to the target ram. It seems to reload the sections just like at startup (step 1). 11. I click in the insight source window. It is still displaying the abort.c code. Probably OK. 12. I hit s (or c) in the source window and insight vanishes. "[1] Segmentation fault" prints in kde Konsole. Note: If I omit step 9, there is no crash in step 12. Also, if I set a breakpoint anywhere in the application and examine a variable with the mouse, insight crashes after the next "so gdbinit" is loaded. I don't actually have to let the program run to completion. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-02 18:19 ` gds @ 2008-04-02 18:41 ` Keith Seitz 2008-06-29 17:56 ` Gene Smith 0 siblings, 1 reply; 18+ messages in thread From: Keith Seitz @ 2008-04-02 18:41 UTC (permalink / raw) To: gds; +Cc: insight My bad... gds wrote: > 10. I go to the insight console window (not gtkterm's) and type gdb cmd > source gdbinit > to redownload the program to the target ram. It seems to reload the > sections just like at startup (step 1). From this I can guess what the problem is. It was not registering with my brain that your gdbinit file changed the state of the target. I'll bet that varballoons in insight are simply not "noticing" that they must discard their state when this occurs. Let me see if I can come up with a test case and a patch... Sorry! Keith ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-02 18:41 ` Keith Seitz @ 2008-06-29 17:56 ` Gene Smith 0 siblings, 0 replies; 18+ messages in thread From: Gene Smith @ 2008-06-29 17:56 UTC (permalink / raw) To: insight Keith Seitz wrote, On 04/02/2008 02:37 PM: > My bad... > > gds wrote: > >> 10. I go to the insight console window (not gtkterm's) and type gdb cmd >> source gdbinit >> to redownload the program to the target ram. It seems to reload the >> sections just like at startup (step 1). > > From this I can guess what the problem is. It was not registering with > my brain that your gdbinit file changed the state of the target. I'll > bet that varballoons in insight are simply not "noticing" that they must > discard their state when this occurs. > > Let me see if I can come up with a test case and a patch... > > Sorry! > > Keith > I haven't been working on this for several months since this bug was reported but now need to get back to it. Was wondering if there has been any progress on a possible patch as mentioned above? Thanks, -gene ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-01 18:00 ` Keith Seitz 2008-04-01 18:48 ` gds @ 2008-04-01 22:12 ` gds 2008-04-01 22:32 ` gds 2008-04-02 17:16 ` gds 2 siblings, 1 reply; 18+ messages in thread From: gds @ 2008-04-01 22:12 UTC (permalink / raw) To: insight Keith Seitz wrote: > > Can you give me a testcase and procedure (hopefully native linux)? The > simple test case I've tried here works. Built and installed native insight from source (no params on configure). See no problems with a simple linux app with balloons, even after doing "so gdbinit" (with gdbinit just containing simple stuff like b main; run). With arm build, gdbinit reloads code to memory via jtag. So a bit more is going on there. FYI, my insight configure params for arm build are this: configure -v --quiet --prefix=/opt/rtems-4.8 --target=arm-rtems4.8 \ --enable-interwork --enable-multilib --with-gnu-ld --with-gnu-as Not sure all of these are needed. The rtems build instructions for gdb (no insight) just includes the --prefix and --target. The other stuff I got from this guy's site: http://openhardware.net/Embedded_ARM/Toolchain/#insightcfg Specifically, his 05makeInsight.sh script. I will build with fewer params on configure and see what happens. Can you tell anything from the backtrace I sent? -gene ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-01 22:12 ` gds @ 2008-04-01 22:32 ` gds 0 siblings, 0 replies; 18+ messages in thread From: gds @ 2008-04-01 22:32 UTC (permalink / raw) To: insight gds wrote: > > I will build with fewer params on configure and see what happens. Made no difference with just --prefix and --target set. > > Can you tell anything from the backtrace I sent? > > -gene ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Crashes when "balloons" enabled 2008-04-01 18:00 ` Keith Seitz 2008-04-01 18:48 ` gds 2008-04-01 22:12 ` gds @ 2008-04-02 17:16 ` gds 2 siblings, 0 replies; 18+ messages in thread From: gds @ 2008-04-02 17:16 UTC (permalink / raw) To: insight Keith Seitz wrote: > gds wrote: > >> Is there a possible work-around for this? > > Can you give me a testcase and procedure (hopefully native linux)? The > simple test case I've tried here works. > > Can you run insight on gdb and get a backtrace of where the thing > crashes? That would be very helpful. > > Keith > http://sources.redhat.com/ml/insight-prs/2006-q2/msg00001.html Look like this bt from insight-6.4 is the same as mine! Interesting that he is using a BDI2000 JTAG debugger device which is similar to the Macraigor mpDemon I am using. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2008-06-29 17:56 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-04-01 17:55 Crashes when "balloons" enabled gds 2008-04-01 18:00 ` Keith Seitz 2008-04-01 18:48 ` gds 2008-04-02 0:02 ` Doug Graham 2008-04-02 14:00 ` gds 2008-04-02 15:52 ` gds 2008-04-02 17:14 ` Doug Graham 2008-04-02 17:23 ` Keith Seitz 2008-04-02 17:44 ` Doug Graham 2008-04-02 18:01 ` Keith Seitz 2008-04-02 20:06 ` Doug Graham 2008-04-02 20:12 ` Keith Seitz 2008-04-02 18:19 ` gds 2008-04-02 18:41 ` Keith Seitz 2008-06-29 17:56 ` Gene Smith 2008-04-01 22:12 ` gds 2008-04-01 22:32 ` gds 2008-04-02 17:16 ` gds
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).