Re: Crashes when "balloons" enabled

["Doug Graham" <dgraham at nortel dot com>]

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