From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27551 invoked by alias); 2 Apr 2008 17:44:30 -0000 Received: (qmail 27542 invoked by uid 22791); 2 Apr 2008 17:44:30 -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 17:44:01 +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 m32HhQb24355 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL); Wed, 2 Apr 2008 17:43:57 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 m32HhOU02052 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 2 Apr 2008 17:43:24 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 m32HhN5q020161; Wed, 2 Apr 2008 13:43:23 -0400 Received: (from dgraham@localhost) by wcary472.ca.nortel.com (8.13.1/8.13.1/Submit) id m32HhNoF020160; Wed, 2 Apr 2008 13:43:23 -0400 Date: Wed, 02 Apr 2008 17:44:00 -0000 From: "Doug Graham" To: Keith Seitz Cc: gds , insight@sources.redhat.com Subject: Re: Crashes when "balloons" enabled Message-ID: <20080402174323.GD6223@nortel.com> References: <47F27765.8040905@redhat.com> <20080402000132.GA6223@nortel.com> <47F3C040.7030802@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47F3C040.7030802@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/msg00015.txt.bz2 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 To: gds 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