public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: "Terekhov, Mikhail" <Mikhail.Terekhov@dell.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Simon Marchi <simon.marchi@efficios.com>
Subject: Re: [PATCH 3/3] gdb: add assertion when marking the remote async flag
Date: Fri, 6 Oct 2023 21:35:45 -0400	[thread overview]
Message-ID: <20aa237c-7e6b-48cb-9456-60b6cd0da4e5@polymtl.ca> (raw)
In-Reply-To: <DM5PR1901MB215098608BF5088C49A96908E5C9A@DM5PR1901MB2150.namprd19.prod.outlook.com>

On 10/6/23 17:09, Terekhov, Mikhail wrote:
>> -----Original Message-----
>> From: Gdb-patches <gdb-patches-
>> bounces+mikhail.terekhov=dell.com@sourceware.org> On Behalf Of Simon
>> Marchi via Gdb-patches
>> Sent: Tuesday, October 3, 2023 10:04 PM
>> To: gdb-patches@sourceware.org
>> Cc: Simon Marchi <simon.marchi@efficios.com>
>> Subject: [PATCH 3/3] gdb: add assertion when marking the remote async flag
>>
>>
>> [EXTERNAL EMAIL]
>>
>> From: Simon Marchi <simon.marchi@efficios.com>
>>
>> As reported in bug 30630 [1], we hit a case where the remote target's async flag
>> is marked while the target is not configured (yet) to work async.  This should not
>> happen.  It is caught thanks to this assert in
>> remote_target::wait:
>>
>>     /* Start by clearing the flag that asks for our wait method to be called,
>>        we'll mark it again at the end if needed.  If the target is not in
>>        async mode then the async token should not be marked.  */
>>     if (target_is_async_p ())
>>       rs->clear_async_event_handler ();
>>     else
>>       gdb_assert (!rs->async_event_handler_marked ());
>>
>> This is helpful, but I think that we could have caught the problem earlier than
>> that, at the moment we marked the handler.  Catching problems earlier makes
>> them easier to debug.
>>
>> [1]
>> https://urldefense.com/v3/__https://sourceware.org/bugzilla/show_bug.cgi?id
>> =30630__;!!LpKI!j0fTzubsC8RVdwinGn-r82-
>> mX7hLUvNffNCQWwFTCYyR9EWj0CtlY9ERyT_AXgqsNQ0ZjS4Ls53fdBnUrLhWIw
>> hIBW9P$ [sourceware[.]org]
>>
>> Change-Id: I7e229c74b04da82bef6a817d5a676be5cf52e833
>> ---
>>  gdb/remote.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/gdb/remote.c b/gdb/remote.c index 38d0027dbf9e..7830b5cec33f
>> 100644
>> --- a/gdb/remote.c
>> +++ b/gdb/remote.c
>> @@ -424,7 +424,10 @@ class remote_state
>>    }
>>
>>    void mark_async_event_handler ()
>> -  { ::mark_async_event_handler (m_async_event_handler_token); }
>> +  {
>> +    gdb_assert (this->is_async_p ());
>> +    ::mark_async_event_handler (m_async_event_handler_token);  }
> 
> This change made the need for fix suggested in [1] more obvious.
> The assert in mark_async_event_handler () is stronger than check in
> remote_target::queued_stop_reply().
> I.e. mark_async_event_handler () should not be called in
> remote_target::queued_stop_reply() unless async_handler != NULL i.e.
> target_is_async_p() !=0.
> 
> I'd suggest to merge in fix from [1] into this series.

Yes, your fix needs to be merged independently of my series.  My series
is only to add an assertion closer to the root of the problem (which
could help catch other problems in the future).

Simon

  reply	other threads:[~2023-10-07  1:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-04  2:03 [PATCH 0/3] Add " Simon Marchi
2023-10-04  2:03 ` [PATCH 1/3] gdb: make remote_state's async token private Simon Marchi
2023-10-09  9:11   ` Andrew Burgess
2023-10-10 14:56     ` Simon Marchi
2023-10-04  2:04 ` [PATCH 2/3] gdb: add remote_state::{is_async_p,can_async_p} Simon Marchi
2023-10-09  9:20   ` Andrew Burgess
2023-10-10 15:01     ` Simon Marchi
2023-10-04  2:04 ` [PATCH 3/3] gdb: add assertion when marking the remote async flag Simon Marchi
2023-10-06 21:09   ` Terekhov, Mikhail
2023-10-07  1:35     ` Simon Marchi [this message]
2023-10-09  9:25   ` Andrew Burgess
2023-10-10 15:01     ` Simon Marchi
2023-10-06 21:28 ` [PATCH 0/3] Add " Terekhov, Mikhail

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=20aa237c-7e6b-48cb-9456-60b6cd0da4e5@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=Mikhail.Terekhov@dell.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@efficios.com \
    /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).