From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25978 invoked by alias); 24 Feb 2005 03:17:55 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25958 invoked from network); 24 Feb 2005 03:17:50 -0000 Received: from unknown (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org with SMTP; 24 Feb 2005 03:17:50 -0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1D49VS-0003Bc-1g; Wed, 23 Feb 2005 19:17:38 -0800 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12071-04; Wed, 23 Feb 2005 19:17:37 -0800 (PST) Received: from [192.168.11.101] (helo=tensilica.com) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1D49VR-0003BW-LB; Wed, 23 Feb 2005 19:17:37 -0800 Message-ID: <421D4751.7000303@tensilica.com> Date: Thu, 24 Feb 2005 03:23:00 -0000 From: Ross Morley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sources.redhat.com Subject: Re: -var-create on invalid expression causes seg. fault References: <16919.48311.476960.352611@farnswood.snap.net.nz> <42184BBA.6030007@tensilica.com> <20050223160026.GA27996@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00154.txt.bz2 Thanks Daniel, very much. That did the trick. I had to translate the exception handling as you mentioned, but I managed to get that done and the problem is solved in our 5.2.1 sources. I have not tried your patch in HEAD. Ross --------------- Ross Morley Tensilica, Inc. ross@tensilica.com Daniel Jacobowitz wrote: >On Sun, Feb 20, 2005 at 12:35:06AM -0800, Ross Morley wrote: > > >>Thanks for your input Nick, but I don't think it's what I need. >> >>I already know exactly where the problem is (I debugged it under gdb). >>What I don't know is the right way to fix it. >>Also I believe this bug exists in 6.3 because the offending code is >>the same, though I haven't tried to reproduce it there. >> >>I should have mentioned that a seg. fault does not always immediately >>result. It just depends how the freed memory is used after it's freed. >>If it's allocated again and its new owner alters the location that was >>var->value to contain 0 or some other bad address, the seg. fault will >>occur. Otherwise the problem may lurk for a long time and show up >>later in some obscure way or not at all. So it's a bit hard to reproduce >>the seg. fault, but if you read my post and run it under gdb you should >>easily be able to verify that a pointer to freed memory is dereferenced. >> >>I'm hoping someone who knows the internals of MI variables can suggest >>a good fix that won't break something else. It's not as simple as >>clearing that hanging pointer... that will just cause a seg. fault >>for sure when the pointer is dereferenced. If no one knows, I'll >>probably just have to dive in and educate myself. >> >> > >Could you give the attached patch a try? I encountered a similar >problem in mi-var-block.exp when using ARM RVDS, which emits location >lists even at -O0. It frequently reports variables as "unavailable", >which is an error condition. > >The patch sets the variable to an error in the -var-update >"unavailable" case; this never passes any error message on to the user, >but that seems to be the prior art for varobj. > >You'll need to use catch_exceptions for your older sources; the patch >is for HEAD. > >[I haven't finished testing any of these patches, that's why I haven't >submitted this to gdb-patches yet.] > > >