[PATCH] [gdb] Prune inferior after switching inferior

[PATCH] [gdb] Prune inferior after switching inferior

[Tom de Vries]

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 ();
     }
 }
 
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
-- 
2.35.3

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

[Tom de Vries]

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.
> 

I just spotted two mistakes in the commit log.

-can't remove inferior 1
+can't remove inferior 2

> 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.
> 

-can remove inferior 1
+can remove inferior 2

I'll update this locally.

Thanks,
- Tom

> 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 ();
>       }
>   }
>   
> 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

[PING][PATCH] [gdb] Prune inferior after switching inferior

[Tom de Vries]

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.

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

[PING^2][PATCH] [gdb] Prune inferior after switching inferior

[Tom de Vries]

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.

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
>