From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15437 invoked by alias); 20 Feb 2005 08:35:22 -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 15215 invoked from network); 20 Feb 2005 08:35:08 -0000 Received: from unknown (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org with SMTP; 20 Feb 2005 08:35:08 -0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1D2mYV-0001zh-EJ; Sun, 20 Feb 2005 00:35:07 -0800 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07370-05; Sun, 20 Feb 2005 00:35:07 -0800 (PST) Received: from [192.168.11.101] (helo=tensilica.com) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1D2mYU-0001zZ-Vv; Sun, 20 Feb 2005 00:35:07 -0800 Message-ID: <42184BBA.6030007@tensilica.com> Date: Sun, 20 Feb 2005 17:44: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: Nick Roberts CC: gdb@sources.redhat.com Subject: Re: -var-create on invalid expression causes seg. fault References: <16919.48311.476960.352611@farnswood.snap.net.nz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00128.txt.bz2 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. Ross Nick Roberts wrote: >>-var-create on an expression that's invalid (eg. "(*1)") >>creates a variable and retains a ptr in var->value. That >>gets freed by free_all_values() next command. Later a >>-var-update or -var-evaluate-expression on that variable >>dereferences the freed memory, causing a seg. fault. >> >> > >Since you have 5.2.1 based sources, you could run it under gdb and the >backtrace should show you where the problem occurs e.g. in the directory of >your source, somthing like: > >/usr/bin/gdb ./gdb >... >(top-gdb) cd ~/ >(top-gdb) run -i=mi myprog >... >(gdb) >-var-create - * *1 >&"Cannot access memory at address 0x1\n" >^done,name="var1",numchild="0",type="int" >(gdb) >-var-update * >&"Cannot access memory at address 0x1\n" >Segmentation fault >(top-gdb) bt >... > > > >>I looked at the GDB 6.3 source and it seems to be the same. >> >> > > > >>Now why would anyone try to evaluate *1? It's some tool that >>uses MI, one of our customers reported. I'm not clear on why >>GDB even creates the variable in this case, but it does. >>GDB should report an error, not crash. >> >> > >GDB in CVS doesn't crash although it does allow a variable object to be set at >a nonsensical address. Perhaps this behaviour should be changed. However, I >don't think people on this list will be generally interested in debugging old >versions of GDB. > > >Nick > > >