Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PING^3][PATCH] [gdb] Prune inferior after switching inferior
Date: Sat, 1 Jun 2024 14:27:34 +0200	[thread overview]
Message-ID: <34c9df7f-224a-4c49-8976-07c049c5408e@suse.de> (raw)
In-Reply-To: <4671abe5-8d01-46fd-a280-6cf9e4c86c1b@suse.de>

On 5/8/24 14:21, Tom de Vries wrote:
> On 3/19/24 10:34, Tom de Vries wrote:
>> On 3/4/24 13:21, Tom de Vries wrote:
>>> Usually with test-case gdb.python/py-progspace-events.exp I get:
>>> ...
>>> (gdb) inferior 1^M
>>> [Switching to inferior 1 [process 4116] (py-progspace-events)]^M
>>> [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 4116))]^M
>>> 28      { /* Nothing.  */ }^M
>>> (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
>>> step^M
>>> FreeProgspaceEvent: <gdb.Progspace object at 0xabf4f850>^M
>>> do_parent_stuff () at py-progspace-events.c:41^M
>>> 41        ++global_var;^M
>>> (gdb) PASS: gdb.python/py-progspace-events.exp: step
>>> ...
>>>
>>> But occasionally I run into the following FAIL:
>>> ...
>>> (gdb) inferior 1^M
>>> [Switching to inferior 1 [process 5199] (py-progspace-events)]^M
>>> [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
>>> 28      { /* Nothing.  */ }^M
>>> (gdb) FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
>>> FAIL: gdb.python/py-progspace-events.exp: inferior 1 (timeout)
>>> ...
>>>
>>> This is caused by a race between the handling of an event, and the
>>> "inferior 1" command.
>>>
>>> In the passing case, the event is handled first.  During which 
>>> prune_inferiors
>>> is called, but it can't remove inferior 1, because it's still the 
>>> current one.
>>>
>>> In the failing case, the "inferior 1" command is handled first.  Then 
>>> during
>>> handling of the event, prune_inferiors is called, and it can remove 
>>> inferior 1
>>> because it's no longer the current one.
>>>
>>> This looks like a test-case issue to me, but ISTM that we can do 
>>> better: by
>>> calling prune_inferiors asap, at the end of the "inferior 1" command, we
>>> stabilize the moment when the inferior is removed:
>>> ...
>>> (gdb) inferior 1^M
>>> [Switching to inferior 1 [process 5199] (py-progspace-events)]^M
>>> [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
>>> 28      { /* Nothing.  */ }^M
>>> FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
>>> (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
>>> ...
>>>
>>> Tested on x86_64-linux.
>>>
>>
>> Ping.
> 
> Ping^2.

Ping^3.


Thanks,
- Tom

>>> PR gdb/31440
>>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440
>>> ---
>>>   gdb/inferior.c                                |  4 +++
>>>   .../gdb.python/py-progspace-events.exp        | 31 +++----------------
>>>   2 files changed, 9 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/gdb/inferior.c b/gdb/inferior.c
>>> index 5ff5eb98955..4e179f7fb80 100644
>>> --- a/gdb/inferior.c
>>> +++ b/gdb/inferior.c
>>> @@ -791,6 +791,10 @@ inferior_command (const char *args, int from_tty)
>>>         notify_user_selected_context_changed
>>>           (USER_SELECTED_INFERIOR);
>>>       }
>>> +
>>> +      /* Switching current inferior may have made one of the inferiors
>>> +     prunable, so prune it.  */
>>> +      prune_inferiors ();
>>>       }
>>>   }
>>> diff --git a/gdb/testsuite/gdb.python/py-progspace-events.exp 
>>> b/gdb/testsuite/gdb.python/py-progspace-events.exp
>>> index 95e4ca8da0b..9dfc7573d40 100644
>>> --- a/gdb/testsuite/gdb.python/py-progspace-events.exp
>>> +++ b/gdb/testsuite/gdb.python/py-progspace-events.exp
>>> @@ -79,37 +79,16 @@ gdb_test "continue" \
>>>        "\\\[Inferior $decimal \[^\r\n\]+ exited normally\\\]"] \
>>>       "continue until inferior 2 exits"
>>> -gdb_test "inferior 1" "\\\[Switching to inferior 1 .*"
>>> -
>>> -# Step the inferior.  During this process GDB will prune the now
>>> +# Switch to inferior 1.  During this process GDB will prune the now
>>>   # defunct inferior, which deletes its program space, which should
>>>   # trigger the FreeProgspaceEvent.
>>>   #
>>> -# However, there is a slight problem.  When the target is remote, and
>>> -# GDB is accessing files using remote fileio, then GDB will attempt to
>>> -# prune the inferior at a point in time when the remote target is
>>> -# waiting for a stop reply.  Pruning an inferior causes GDB to close
>>> -# files associated with that inferior.
>>> -#
>>> -# In non-async mode we can't send fileio packets while waiting for a
>>> -# stop reply, so the attempts to close files fails, and this shows up
>>> -# as an error.
>>> -#
>>> -# As this error has nothing to do with the feature being tested here,
>>> -# we just accept the error message, the important part is the
>>> -# 'FreeProgspaceEvent' string, so long as that appears (just once)
>>> -# then the test is a success.
>>> -set warning_msg \
>>> -    [multi_line \
>>> -     "warning: cannot close \"\[^\r\n\]+\": Cannot execute this 
>>> command while the target is running\\." \
>>> -     "Use the \"interrupt\" command to stop the target" \
>>> -     "and then try again\\."]
>>> -gdb_test "step" \
>>> +gdb_test "inferior 1" \
>>>       [multi_line \
>>> -     "^FreeProgspaceEvent.*: <gdb.Progspace object at 
>>> $hex>(?:\r\n$warning_msg)*" \
>>> -     "do_parent_stuff \\(\\) at \[^\r\n\]+" \
>>> -     "$decimal\\s+\[^\r\n\]+"]
>>> +     "\\\[Switching to inferior 1 .*" \
>>> +     ".*" \
>>> +     "FreeProgspaceEvent.*: <gdb.Progspace object at $hex>"]
>>>   # Let this inferior run to completion.
>>>   gdb_continue_to_end
>>>
>>> base-commit: 1485a3fb63619cced99dd7a4a043cf01a0f423d9
>>
> 


  reply	other threads:[~2024-06-01 12:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-04 12:21 [PATCH] " Tom de Vries
2024-03-04 12:26 ` Tom de Vries
2024-03-19  9:34 ` [PING][PATCH] " Tom de Vries
2024-05-08 12:21   ` [PING^2][PATCH] " Tom de Vries
2024-06-01 12:27     ` Tom de Vries [this message]
2024-06-30 20:18 ` [PATCH] " Kevin Buettner
2024-07-23  9:35   ` Tom de Vries
2024-07-31  7:50     ` Tom de Vries

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=34c9df7f-224a-4c49-8976-07c049c5408e@suse.de \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.org \
    /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