From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27979 invoked by alias); 19 Feb 2005 22:27:26 -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 27906 invoked from network); 19 Feb 2005 22:27:16 -0000 Received: from unknown (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org with SMTP; 19 Feb 2005 22:27:16 -0000 Received: from farnswood.snap.net.nz (p6-tnt2.snap.net.nz [202.124.108.6]) by viper.snap.net.nz (Postfix) with ESMTP id 4F1CD403176; Sun, 20 Feb 2005 11:26:22 +1300 (NZDT) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 8876962FBE; Sat, 19 Feb 2005 22:24:56 +0000 (GMT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16919.48311.476960.352611@farnswood.snap.net.nz> Date: Sat, 19 Feb 2005 23:10:00 -0000 To: Ross Morley Cc: gdb@sources.redhat.com Subject: Re: -var-create on invalid expression causes seg. fault X-SW-Source: 2005-02/txt/msg00126.txt.bz2 > One of our customers reported GDB crashing when an MI > variable is created on an invalid address and then referenced. > I've debugged to the point of finding the cause, but am not > knowledgable enough on the MI variables to know the right > way to fix it. I filed a bug report because this needs > to get fixed in the latest sources. I'd appreciate any > insight so I can fix it in our 5.2.1 based sources. > I don't have the time to look deeper, but someone on this > list is familiar with this stuff I'm sure. > -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