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.]