[PATCH][gdb/testsuite] Fix gdb.threads/killed-outside.exp with -m32

[PATCH][gdb/testsuite] Fix gdb.threads/killed-outside.exp with -m32

[Tom de Vries]

Hi,

When running test-case gdb.threads/killed-outside.exp with target board
unix/-m32, we run into:
...
(gdb) PASS: gdb.threads/killed-outside.exp: get pid of inferior
Executing on target: kill -9 10969    (timeout = 300)
spawn -ignore SIGHUP kill -9 10969^M
continue^M
Continuing.^M
[Thread 0xf7cb4b40 (LWP 10973) exited]^M
^M
Program terminated with signal SIGKILL, Killed.^M
The program no longer exists.^M
(gdb) FAIL: gdb.threads/killed-outside.exp: prompt after first continue
...

Fix this by allowing this output.

Tested on x86_64-linux.

Any comments?

Thanks,
- Tom

[gdb/testsuite] Fix gdb.threads/killed-outside.exp with -m32

gdb/testsuite/ChangeLog:

2021-01-18  Tom de Vries  <tdevries@suse.de>

	* gdb.threads/killed-outside.exp: Allow regular output.

---
 gdb/testsuite/gdb.threads/killed-outside.exp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gdb/testsuite/gdb.threads/killed-outside.exp b/gdb/testsuite/gdb.threads/killed-outside.exp
index 303328dd27a..7050a4b84ba 100644
--- a/gdb/testsuite/gdb.threads/killed-outside.exp
+++ b/gdb/testsuite/gdb.threads/killed-outside.exp
@@ -54,4 +54,7 @@ gdb_test_multiple "continue" "prompt after first continue" {
 	    }
 	}
     }
+    -re -wrap ".*$killed_msg.*$no_longer_exists_msg" {
+	pass $gdb_test_name
+    }
 }

Re: [PATCH][gdb/testsuite] Fix gdb.threads/killed-outside.exp with -m32

[Luis Machado]

I was looking at this test on aarch64-linux/x86_64-linux Ubuntu 20.04 
and noticed inconsistent output. I'm trying to assess what is the best 
course of action.

On 1/18/21 8:44 AM, Tom de Vries wrote:
> Hi,
> 
> When running test-case gdb.threads/killed-outside.exp with target board
> unix/-m32, we run into:
> ...
> (gdb) PASS: gdb.threads/killed-outside.exp: get pid of inferior
> Executing on target: kill -9 10969    (timeout = 300)
> spawn -ignore SIGHUP kill -9 10969^M
> continue^M
> Continuing.^M
> [Thread 0xf7cb4b40 (LWP 10973) exited]^M
> ^M
> Program terminated with signal SIGKILL, Killed.^M
> The program no longer exists.^M
> (gdb) FAIL: gdb.threads/killed-outside.exp: prompt after first continue
> ...
> 
> Fix this by allowing this output.
> 
> Tested on x86_64-linux.
> 
> Any comments?
> 
> Thanks,
> - Tom


I see the following output, most of the time:

Executing on target: kill -9 3742839    (timeout = 300)
spawn -ignore SIGHUP kill -9 3742839^M
continue^M
Continuing.^M
Unable to fetch general registers.: No such process.^M
(gdb) [Thread 0xfffff7e281e0 (LWP 3742842) exited]^M
^M
Program terminated with signal SIGKILL, Killed.^M
The program no longer exists.^M
FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout)

But I also see the following with READ1:

Executing on target: kill -9 3743271    (timeout = 300)
spawn -ignore SIGHUP kill -9 3743271^M
continue^M
Continuing.^M
Unable to fetch general registers.: No such process.^M
(gdb) FAIL: gdb.threads/killed-outside.exp: prompt after first continue

Besides the messages not being the same, there is some odd inconsistency 
with the prompt positioning compared to what you mentioned above.

Forcing scheduler-locking to on made the output consistent for both 
cases, but I was left wondering if enabling scheduler-locking would 
cause the bug to not be reproducible anymore.

Thoughts?

Re: [PATCH][gdb/testsuite] Fix gdb.threads/killed-outside.exp with -m32

[Pedro Alves]

On 13/04/21 14:33, Luis Machado wrote:
> 
> Forcing scheduler-locking to on made the output consistent for both cases, but I was left wondering if enabling scheduler-locking would cause the bug to not be reproducible anymore.

Yeah, no.  That would just paper over problems.  GDB should cope with threads disappearing beneath it, as they're resumed, stopped, etc.  Forcing scheduler-locking just
means you're only resuming one thread instead of many, and thus reducing the chances of some GDB issue triggering.  Wouldn't be much different from making the testcase
be single-threaded.

Pedro Alves

Re: [PATCH][gdb/testsuite] Fix gdb.threads/killed-outside.exp with -m32

[Luis Machado]

On 4/13/21 11:45 AM, Pedro Alves wrote:
> On 13/04/21 14:33, Luis Machado wrote:
>>
>> Forcing scheduler-locking to on made the output consistent for both cases, but I was left wondering if enabling scheduler-locking would cause the bug to not be reproducible anymore.
> 
> Yeah, no.  That would just paper over problems.  GDB should cope with threads disappearing beneath it, as they're resumed, stopped, etc.  Forcing scheduler-locking just
> means you're only resuming one thread instead of many, and thus reducing the chances of some GDB issue triggering.  Wouldn't be much different from making the testcase
> be single-threaded.

Right. The non-deterministic nature of the output makes it harder to 
find a reliable pattern to match.

There seems to be a couple issues at play here. One is the 
non-deterministic ordering of thread-related outputs, which is expected 
and we can't do much about it. Though I'd expect a thread exit 
notification to always show up, and not be swallowed by GDB.

The other is the non-deterministic position of the gdb prompt, even for 
all-stop mode. Sometimes it shows up before GDB gets a chance to output 
other messages, like so:

Executing on target: kill -9 3742839    (timeout = 300)
spawn -ignore SIGHUP kill -9 3742839^M
continue^M
Continuing.^M
Unable to fetch general registers.: No such process.^M
(gdb) [Thread 0xfffff7e281e0 (LWP 3742842) exited]^M
^M
Program terminated with signal SIGKILL, Killed.^M
The program no longer exists.^M
FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout)

I was considering the possibility of adjusting the test, but I may be 
dealing with other GDB bugs.

Re: [PATCH][gdb/testsuite] Fix gdb.threads/killed-outside.exp with -m32

[Pedro Alves]

On 13/04/21 16:51, Luis Machado wrote:
> On 4/13/21 11:45 AM, Pedro Alves wrote:
>> On 13/04/21 14:33, Luis Machado wrote:
>>>
>>> Forcing scheduler-locking to on made the output consistent for both cases, but I was left wondering if enabling scheduler-locking would cause the bug to not be reproducible anymore.
>>
>> Yeah, no.  That would just paper over problems.  GDB should cope with threads disappearing beneath it, as they're resumed, stopped, etc.  Forcing scheduler-locking just
>> means you're only resuming one thread instead of many, and thus reducing the chances of some GDB issue triggering.  Wouldn't be much different from making the testcase
>> be single-threaded.
> 
> Right. The non-deterministic nature of the output makes it harder to find a reliable pattern to match.
> 
> There seems to be a couple issues at play here. One is the non-deterministic ordering of thread-related outputs, which is expected and we can't do much about it. Though I'd expect a thread exit notification to always show up, and not be swallowed by GDB.
> 
> The other is the non-deterministic position of the gdb prompt, even for all-stop mode. Sometimes it shows up before GDB gets a chance to output other messages, like so:
> 
> Executing on target: kill -9 3742839    (timeout = 300)
> spawn -ignore SIGHUP kill -9 3742839^M
> continue^M
> Continuing.^M
> Unable to fetch general registers.: No such process.^M
> (gdb) [Thread 0xfffff7e281e0 (LWP 3742842) exited]^M
> ^M
> Program terminated with signal SIGKILL, Killed.^M
> The program no longer exists.^M
> FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout)
> 

That's a GDB bug.  GDB shouldn't have given the prompt so soon.  I think it did because
the "No such process" error escapes out.