From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5325 invoked by alias); 23 Jan 2007 14:49:31 -0000 Received: (qmail 5303 invoked by uid 22791); 23 Jan 2007 14:49:28 -0000 X-Spam-Check-By: sourceware.org Received: from vir-del-03.spheriq.net (HELO vir-del-03.spheriq.net) (194.50.41.42) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 Jan 2007 14:49:18 +0000 Received: from vir-out-01.spheriq.net ([194.50.41.30]) by vir-del-03.spheriq.net with ESMTP id l0NERRXf008203 for ; Tue, 23 Jan 2007 14:27:27 GMT Received: from vir-cus-02.spheriq.net (vir-cus-02.spheriq.net [194.50.41.86]) by vir-out-01.spheriq.net with ESMTP id l0NERQ0T023218 for ; Tue, 23 Jan 2007 14:27:26 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by vir-cus-02.spheriq.net with ESMTP id l0NERNjr011198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jan 2007 14:27:25 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9607DDA46; Tue, 23 Jan 2007 14:27:20 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 38F8A474E0; Tue, 23 Jan 2007 14:27:17 +0000 (GMT) Received: from [164.129.44.95] (crx595.cro.st.com [164.129.44.95]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CJM30439 (AUTH "denis pilat"); Tue, 23 Jan 2007 15:27:13 +0100 (CET) Message-ID: <45B61B41.90509@st.com> Date: Tue, 23 Jan 2007 14:49:00 -0000 From: Denis PILAT User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] varobj deletion after the binary has changed References: <45B60056.6030704@st.com> <20070123124457.GA1600@nevyn.them.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-01/txt/msg00478.txt.bz2 Vladimir Prus wrote: > And what kind of problems does it cause, for the record? I'd expect that > attempt of evaluating such expressions will result in value being "", > and in_scope="false". Do you get anything worse than that? > Yes we are, gdb crashes. In our case, when the -exec-run reloads the binary file, it stops at a breakpoint previously set and the frame_id is exactly the same as the one stored in the varobj object during the previous run (our SP does not change, under linux native targets, it is "randomized" I guess.). So when front-end executes -var-update, GDB thinks the varobj refers to a valid frame (but it's wrong since the program has changed) and try to access stuff he should not. There is a way to reproduce it under native linux target: Compile the following source file to get "a.out" #include int a_global = 0; int main() { printf("hello"); a_global++; return a_global; } Run "gdb -i mi a.out" and the following command: -var-create varname * a_global shell touch a.out 70-break-insert -t main 71-exec-run 75-var-update varname ==> you got it ! (Segmentation fault) > Or maybe, implement "binary changed" MI notification that can be used > by the frontend as it sees fit. > That's a good option for the front end to make cleanup in its "watched" variable but it won't fix the current problem. -- Denis