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

[Ross Morley <ross@tensilica.com>]

Thanks Daniel, very much. That did the trick.
I had to translate the exception handling as you mentioned,
but I managed to get that done and the problem is solved
in our 5.2.1 sources. I have not tried your patch in HEAD.

Ross

---------------
Ross Morley
Tensilica, Inc.
ross@tensilica.com


Daniel Jacobowitz wrote:

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