From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29297 invoked by alias); 8 Feb 2007 17:41:44 -0000 Received: (qmail 29233 invoked by uid 22791); 8 Feb 2007 17:41:43 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 08 Feb 2007 17:41:34 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1HFDH1-0004Y2-Fv; Thu, 08 Feb 2007 12:41:31 -0500 Date: Thu, 08 Feb 2007 17:41:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Catch errors in value_get_print_value Message-ID: <20070208174131.GC13544@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sourceware.org References: <17858.21211.33629.685339@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17858.21211.33629.685339@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00088.txt.bz2 On Fri, Feb 02, 2007 at 09:51:39AM +1300, Nick Roberts wrote: > > Currently when common_val_print throws an error from install_new_value it gets > caught in mi_execute_command and prints an MI error (^error,...) without > cleaning up. This patch catches the error in value_get_print_value so that GDB > can proceed normally. It could be adapted to output something like > "" but I think the empty string works better. Could you explain why? I would be confused to see an empty value in my locals window. That's separate from this bug though. > ! TRY_CATCH (except, RETURN_MASK_ERROR) > ! { > ! common_val_print (value, stb, format_code[(int) format], 1, 0, 0); > ! } > ! val_print, called by common_val_print, already has code to catch this error and prettyprint it. It doesn't work in this case, through common_val_print, because of: #2 0x0000000000445abd in memory_error (status=5, memaddr=4) at /space/fsf/commit/src/gdb/corefile.c:229 #3 0x00000000004aac7f in value_fetch_lazy (val=0x9688c0) at /space/fsf/commit/src/gdb/valops.c:549 #4 0x00000000004a2f2f in value_contents_all (value=0x9688c0) at /space/fsf/commit/src/gdb/value.c:331 #5 0x00000000004b19a4 in common_val_print (val=0x9688c0, stream=0x94a6b0, format=0, deref_ref=1, recurse=0, pretty=Val_no_prettyprint) at /space/fsf/commit/src/gdb/valprint.c:284 I tried handling the error in value_check_printable. That doesn't have quite the results that I wanted, because if install_new_value is called first it sets value = NULL instead of leaving the unfetchable value there. That's what happens for a1. That gave me an idea. The error only arises for b1 in your testcase, where initial && !changeable and indeed we never use var->print_value if !changeable. So avoiding common_val_print in that case avoids the error. So I checked this in instead. Let me know if it doesn't work for you. -- Daniel Jacobowitz CodeSourcery 2007-02-08 Daniel Jacobowitz * varobj.c (install_new_value): Only call value_get_print_value if changeable. Index: varobj.c =================================================================== RCS file: /cvs/src/src/gdb/varobj.c,v retrieving revision 1.82 diff -u -p -r1.82 varobj.c --- varobj.c 24 Jan 2007 19:54:13 -0000 1.82 +++ varobj.c 8 Feb 2007 17:38:36 -0000 @@ -953,7 +953,7 @@ install_new_value (struct varobj *var, s /* If the type is changeable, compare the old and the new values. If this is the initial assignment, we don't have any old value to compare with. */ - if (initial) + if (initial && changeable) var->print_value = value_get_print_value (value, var->format); else if (changeable) {