Crashes when "balloons" enabled

Crashes when "balloons" enabled

[gds]

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

Re: Crashes when "balloons" enabled

[Keith Seitz]

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

Re: Crashes when "balloons" enabled

[gds]

[-- 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)

Re: Crashes when "balloons" enabled

[gds]

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

Re: Crashes when "balloons" enabled

[gds]

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

Re: Crashes when "balloons" enabled

[Doug Graham]

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)

Re: Crashes when "balloons" enabled

[gds]

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

Re: Crashes when "balloons" enabled

[gds]

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);
   }

Re: Crashes when "balloons" enabled

[Doug Graham]

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);
  }

Re: Crashes when "balloons" enabled

[gds]

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.

Re: Crashes when "balloons" enabled

[Keith Seitz]

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

Re: Crashes when "balloons" enabled

[Doug Graham]

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

Re: Crashes when "balloons" enabled

[Keith Seitz]

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

Re: Crashes when "balloons" enabled

[gds]

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.

Re: Crashes when "balloons" enabled

[Keith Seitz]

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

Re: Crashes when "balloons" enabled

[Doug Graham]

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.

Re: Crashes when "balloons" enabled

[Keith Seitz]

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

Re: Crashes when "balloons" enabled

[Gene Smith]

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