From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2283 invoked by alias); 21 Nov 2005 11:31:51 -0000 Received: (qmail 2273 invoked by uid 22791); 21 Nov 2005 11:31:50 -0000 X-Spam-Check-By: sourceware.org Received: from mail.teleca.fr (HELO mail-server.teleca.fr) (81.80.22.198) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Nov 2005 11:31:50 +0000 Received: from exchange.teleca.fr (exchange.teleca.fr [10.24.16.21]) by mail-server.teleca.fr (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id jALBVXug013902; Mon, 21 Nov 2005 12:31:33 +0100 Received: from [10.24.16.11] ([10.24.16.11]) by exchange.teleca.fr with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 Nov 2005 12:31:33 +0100 Message-ID: <4381B014.9040901@free.fr> Date: Mon, 21 Nov 2005 11:53:00 -0000 From: elmer User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: Keith Seitz CC: insight@sourceware.org Subject: Re: Insight crashing when debugging invalid pointers References: <1132311131.437db25b30ca0@imp2-g19.free.fr> <437E575D.2000709@redhat.com> In-Reply-To: <437E575D.2000709@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact insight-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sourceware.org X-SW-Source: 2005-q4/txt/msg00034.txt.bz2 >> But if insight is trying to display the same things (either using >> tooltips or >> watch), the entire Insight is crashing !!! >> >> I thing it is related variable evaluation like {$val value} >> I checked the Insight scripts, all calls to {$val value} are secured >> with >> 'catch'. >> Is "catch {$val value} result" supposed to catch GDB exceptions ??? >> >> I wonder if this behavior is specific to my built/target or more >> generic ... > > > Good guess. It's probably a problem in varobj (which is part of gdb). > Can you run insight on gdb and get a backtrace of where it dies? > > Keith Unfortunately, it is not very easy for me to have a native gdb to debug insight .... But I think I have found the problem (you're right in varobj.c) : - When gdb tries to evaluate a value, it calls many functions and subfunctions. One of these is "value_of_child" When value_of_child cannot acces memory to evaluate a value, it simply return NULL (deletes the value context) instead of reporting the error. I changed : if (!gdb_value_fetch_lazy (value)) value = NULL; to: if (!gdb_value_fetch_lazy (value)) parent->error = 1; All functions calling this one are testing the "->error" flag or NULL return value. So it works ! But this patch does not delete the value context as it was done previously.... So further use of the value (for types, names,...) are still possible. Previously, Insight was crashing when trying to get the 'type' of this variable. I made another patch in function "my_value_equal" (it assumes that variable can be accessed) : I changed : gdb_assert (!value_lazy (val1)); to: if (value_lazy (val1)) { *error2 = 1; return 0; } With both these patches, Insight is able to display invalid pointers location with an error message set by gdbtk-varobj.c:variable_value By the way, in case of error reported by varobj_get_value, variable_value sets an error messages and returns TCL_ERROR to the caller. But it seems that "catch {$val value} result" does not catch the error ... How to catch it ? Thanks, Elmer.