Re: [RFC] varobj deletion after the binary has changed

[Denis PILAT <denis dot pilat at st dot com>]

Vladimir Prus wrote:
> And what kind of problems does it cause, for the record? I'd expect that
> attempt of evaluating such expressions will result in value being "",
> and in_scope="false". Do you get anything worse than that?
>   
Yes we are, gdb crashes.
In our case, when the -exec-run reloads the binary file, it stops at a 
breakpoint previously set and the frame_id is exactly the same as the 
one stored in the varobj object during the previous run (our SP does not 
change, under linux native targets, it is "randomized" I guess.). So 
when front-end executes -var-update, GDB thinks the varobj refers to a 
valid frame (but it's wrong since the program has changed) and try to 
access stuff he should not.

There is a way to reproduce it under native linux target:
Compile the following source file to get "a.out"
   #include <stdio.h>
   int a_global = 0;
   int main()
   {
     printf("hello");
     a_global++;
     return a_global;
   }

Run "gdb -i mi a.out" and the following command:
   -var-create varname * a_global
   shell touch a.out
   70-break-insert -t main
   71-exec-run
   75-var-update varname

==> you got it ! (Segmentation fault)

> Or maybe, implement "binary changed" MI notification that can be used
> by the frontend as it sees fit.
>   
That's a good option for the front end to make cleanup in its "watched" 
variable but it won't fix the current problem.

--
Denis