This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: varobj/1873: -var-create on invalid expression causes seg. fault
- From: Ross Morley <ross at tensilica dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 4 Jan 2006 18:58:01 -0000
- Subject: Re: varobj/1873: -var-create on invalid expression causes seg. fault
- Reply-to: 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
>
>
>