gdb/mi: fix use after free of frame_info causing spurious notifications
authorAndrew Burgess <aburgess@redhat.com>
Wed, 23 Mar 2022 19:00:35 +0000 (19:00 +0000)
committerAndrew Burgess <aburgess@redhat.com>
Tue, 29 Mar 2022 09:46:44 +0000 (10:46 +0100)
commit9e6a252c062f9cee69007d9ba19eea5e89e675f4
tree3da18340950e80a1c5cc3156950cd0a99b6d1a1c
parentddfc2f56d5782af79c696d7fef7c73bba11e8b09
gdb/mi: fix use after free of frame_info causing spurious notifications

In commit:

  commit a2757c4ed693cef4ecc4dcdcb2518353eb6b3c3f
  Date:   Wed Mar 16 15:08:22 2022 +0000

      gdb/mi: consistently notify user when GDB/MI client uses -thread-select

Changes were made to GDB to address some inconsistencies in when
notifications are sent from a MI terminal to a CLI terminal (when
multiple terminals are in use, see new-ui command).

Unfortunately, in order to track when the currently selected frame has
changed, that commit grabs a frame_info pointer before and after an MI
command has executed, and compares the pointers to see if the frame
has changed.

This is not safe.

If the frame cache is deleted for any reason then the frame_info
pointer captured before the command started, is no longer valid, and
any comparisons based on that pointer are undefined.

This was leading to random test failures for some folk, see:

  https://sourceware.org/pipermail/gdb-patches/2022-March/186867.html

This commit changes GDB so we no longer hold frame_info pointers, but
instead store the frame_id and frame_level, this is safe even when the
frame cache is flushed.
gdb/mi/mi-main.c