This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]