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

[Ross Morley <ross@tensilica.com>]

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