public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: Jan Vrany <jan.vrany@labware.com>,
	Simon Marchi <simon.marchi@polymtl.ca>,
	Simon Marchi <simark@simark.ca>,
	gdb-patches@sourceware.org
Subject: Re: [pushed] gdb/mi: consistently notify user when GDB/MI client uses -thread-select
Date: Wed, 23 Mar 2022 19:09:42 +0000	[thread overview]
Message-ID: <87fsn8scy1.fsf@redhat.com> (raw)
In-Reply-To: <e7517ece8f9ca7540bc228f960dc55afc8cf226f.camel@labware.com>

Jan Vrany via Gdb-patches <gdb-patches@sourceware.org> writes:

> On Wed, 2022-03-23 at 11:16 -0400, Simon Marchi wrote:
>> > I gave it a go but I'm sorry: everything seem to work as expected 
>> > here. I do not get "[Switching to thread 1 (process 1891548)]" message
>> > on CLI when -thread-select already selected thread. 
>> 
>> Ok, strange.
>> 
>> > I must be doing something differently. What commit is failing for you?
>> > What's your ./configure incantation?
>> 
>> My configure arguments are:
>> 
>> 'CC=ccache gcc-11' 'CXX=ccache g++-11' '--disable-binutils' '--disable-gold' '--disable-ld' '--disable-gprof' '--disable-gas' '--with-guile' 'CFLAGS=-g3 -O0
>> -fdiagnostics-color=always -fmax-errors=1 -fsanitize=address' 'CXXFLAGS=-std=c++11 -g3 -O0 -fdiagnostics-color=always -fmax-errors=1 -fsanitize=address -
>> D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1 -D_GLIBCXX_SANITIZE_VECTOR=1' 'LDFLAGS=-fuse-ld=lld -fsanitize=address' '--prefix=/usr' '--enable-ubsan' '--
>> with-python=python3' '--with-debuginfod' '--enable-silent-rules' '--enable-werror'
>> 
>
> Thanks! Now it is failing for me too! 
> I just recompiled GDB using the above command. I'll have a 
> look tomorrow. 

These failures are totally my fault.  Sorry!

The patch below should fix the problem.  Let me know what you think.

Thanks,
Andrew

---

commit fcac0d17e64a18e0600372c2bed51f9e2d9e9d6a
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Wed Mar 23 19:00:35 2022 +0000

    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.

diff --git a/gdb/mi/mi-main.c b/gdb/mi/mi-main.c
index abd033b22ae..4f32bb58939 100644
--- a/gdb/mi/mi-main.c
+++ b/gdb/mi/mi-main.c
@@ -1974,27 +1974,40 @@ struct user_selected_context
 {
   /* Constructor.  */
   user_selected_context ()
-    : m_previous_ptid (inferior_ptid),
-      m_previous_frame (deprecated_safe_get_selected_frame ())
-  { /* Nothing.  */ }
+    : m_previous_ptid (inferior_ptid)
+  {
+    save_selected_frame (&m_previous_frame_id, &m_previous_frame_level);
+  }
 
   /* Return true if the user selected context has changed since this object
      was created.  */
   bool has_changed () const
   {
+    /* Grab details of the currently selected frame, for comparison.  */
+    frame_id current_frame_id;
+    int current_frame_level;
+    save_selected_frame (&current_frame_id, &current_frame_level);
+
+    /* If we end up trying to compare two invalid frame-id's then these
+       will always report themselves as not equal.  However, if we are at
+       the top-most level of the stack then we don't want to consider this
+       as a frame change.  */
     return ((m_previous_ptid != null_ptid
 	     && inferior_ptid != null_ptid
 	     && m_previous_ptid != inferior_ptid)
-	    || m_previous_frame != deprecated_safe_get_selected_frame ());
+	    || current_frame_level != m_previous_frame_level
+	    || (current_frame_level != -1
+		&& !frame_id_eq (current_frame_id, m_previous_frame_id)));
   }
 private:
   /* The previously selected thread.  This might be null_ptid if there was
      no previously selected thread.  */
   ptid_t m_previous_ptid;
 
-  /* The previously selected frame.  This might be nullptr if there was no
-     previously selected frame.  */
-  frame_info *m_previous_frame;
+  /* The previously selected frame.  The frame_id might be null_frame_id
+     if no frame is currently selected.  */
+  frame_id m_previous_frame_id;
+  int m_previous_frame_level;
 };
 
 static void


  reply	other threads:[~2022-03-23 19:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16 15:09 Jan Vrany
2022-03-21 20:35 ` Simon Marchi
2022-03-21 21:01   ` Jan Vrany
2022-03-22 14:37     ` Jan Vrany
2022-03-23 12:36       ` Simon Marchi
2022-03-23 15:13         ` Jan Vrany
2022-03-23 15:16           ` Simon Marchi
2022-03-23 16:09             ` Jan Vrany
2022-03-23 19:09               ` Andrew Burgess [this message]
2022-03-23 19:11                 ` Andrew Burgess
2022-03-23 20:33                 ` Jan Vrany
2022-03-24 14:47                 ` Simon Marchi
2022-03-24 18:52                   ` [PATCHv2] gdb/mi: fix use after free of frame_info causing spurious notifications Andrew Burgess
2022-03-24 20:32                     ` Simon Marchi
2022-03-29 10:10                       ` Andrew Burgess
2022-03-24 15:00               ` [pushed] gdb/mi: consistently notify user when GDB/MI client uses -thread-select Simon Marchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fsn8scy1.fsf@redhat.com \
    --to=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.vrany@labware.com \
    --cc=simark@simark.ca \
    --cc=simon.marchi@polymtl.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).