Re: varobj/1873: -var-create on invalid expression causes seg. fault

[Ross Morley <ross at tensilica dot com>]

The following reply was made to PR varobj/1873; it has been noted by GNATS.

From: Ross Morley <ross@tensilica.com>
To: ramana.radhakrishnan@codito.com
Cc: gdb-gnats@sources.redhat.com,  nobody@sources.redhat.com, 
 gdb-prs@sources.redhat.com, Daniel Jacobowitz <drow@false.org>
Subject: Re: varobj/1873: -var-create on invalid expression causes seg.	fault
Date: Wed, 04 Jan 2006 10:51:19 -0800

 Hi Ramana,
 
 This goes back a ways. The bug was in 5.2.1 and I fixed it in our sources
 by adding
     release_value(var->value);
 after the call to evaluate_type(), after consulation with Daniel Jacobowitz
 (Daniel had a patch he hadn't yet tested. I am not set up to with CVS head).
 
 Please note it is NOT obvious that this bug is fixed just because it doesn't
 seg. fault. The seg. fault depends on how the freed memory is used later.
 See my earlier email included below, 3rd paragraph.
 
 I hate to close a bug without understanding how it got fixed. :-)
 
 You can search the gdb list archives for previous discussion on this in Feb
 2005 under the subject "-var-create on invalid expression causes seg. 
 fault".
 
 Ross
 
 
 
 Ramana Radhakrishnan wrote:
 
 >http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1873
 >
 >With CVS head as on today : GNU gdb 6.4.50.20060104-cvs . this problem does not occur. Can this be closed ? 
 >
 >  
 >
 
 
 -------- Original Message --------
 Subject: 	Re: -var-create on invalid expression causes seg. fault
 Date: 	Sun, 20 Feb 2005 00:35:06 -0800
 From: 	Ross Morley <ross@tensilica.com>
 To: 	Nick Roberts <nickrob@snap.net.nz>
 CC: 	gdb@sources.redhat.com
 References: 	<16919.48311.476960.352611@farnswood.snap.net.nz>
 
 
 
 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
 >
 >  
 >