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

[Denis PILAT <denis.pilat@st.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