From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2601 invoked by alias); 2 Apr 2008 20:06:18 -0000 Received: (qmail 2588 invoked by uid 22791); 2 Apr 2008 20:06:16 -0000 X-Spam-Check-By: sourceware.org Received: from zrtps0kn.nortel.com (HELO zrtps0kn.nortel.com) (47.140.192.55) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Apr 2008 20:05:52 +0000 Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m32K5lb22518 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Wed, 2 Apr 2008 20:05:48 GMT Received: from wcary472.ca.nortel.com (wcary472.ca.nortel.com [47.129.73.197]) by zrtps0m6.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m32K5ic12955 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 2 Apr 2008 20:05:45 GMT Received: from wcary472.ca.nortel.com (localhost [127.0.0.1]) by wcary472.ca.nortel.com (8.13.1/8.12.11) with ESMTP id m32K5ikv020776; Wed, 2 Apr 2008 16:05:44 -0400 Received: (from dgraham@localhost) by wcary472.ca.nortel.com (8.13.1/8.13.1/Submit) id m32K5hC5020775; Wed, 2 Apr 2008 16:05:43 -0400 Date: Wed, 02 Apr 2008 20:06:00 -0000 From: "Doug Graham" To: Keith Seitz Cc: gds , insight@sources.redhat.com Subject: Re: Crashes when "balloons" enabled Message-ID: <20080402200543.GE6223@nortel.com> References: <47F27765.8040905@redhat.com> <20080402000132.GA6223@nortel.com> <47F3C040.7030802@redhat.com> <20080402174323.GD6223@nortel.com> <47F3C933.9080904@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47F3C933.9080904@redhat.com> User-Agent: Mutt/1.4.1i X-IsSubscribed: yes Mailing-List: contact insight-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00019.txt.bz2 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.