Re: [PATCH] [gdb] Prune inferior after switching inferior

Tom de Vries
2024-07-23T09:35:26Z

On 6/30/24 22:18, Kevin Buettner wrote:
> Hi Tom,
>
> See my comments inline below...
>
> On Mon, 4 Mar 2024 13:21:20 +0100
> Tom de Vries <tdevries@suse.de> 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.
>>
>> 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 ();
>> }
>> }
>>
>
> This seems reasonable to me.
>
>> 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>"]
>

Hi Kevin,

thanks for the review.

> It appears that you've removed a test here. I'm guessing that the
> removed test, "step", was being done in order to trigger the event,
> but now that the inferior is being pruned when switching inferiors,
> the event happens at that time. If this reasoning is correct, I think
> it'd be worth mentioning it in the commit log.
>

Your reasoning is correct, I'll submit a v2 with updated commit log.

> Is it the case that the problem(s) mentioned in the removed comments
> have been fixed as well?
>

I didn't bother with that problem, because the test-case mentions "this
error has nothing to do with the feature being tested here".

But since you ask, I've tried to modify the test-case to trigger the
problem in a way that would still work with this patch applied, hoping
that that would provide me with an easy answer.

However, I ran into a problem where exiting an inferior in the
background changes the active inferior. I've filed this as a PR
( https://sourceware.org/bugzilla/show_bug.cgi?id=31988 ), but perhaps
this is expected behaviour, I'm not sure.

So unfortunately, my answer is that I don't know whether the problem has
been fixed as well. I don't understand the code well enough to be able
to reason about this.

Thanks,
- Tom