This is the mail archive of the insight@sourceware.org mailing list for the Insight project.


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

Re: Crashes when "balloons" enabled


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.


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