[Bug gdb/29036] [gdb][testcase-failure, taskset] FAIL: gdb.mi/mi-multi-commands.exp: args=separate-mi-tty: look for first command output, command length 234

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29036

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Andrew Burgess from comment #2)
> Hi Tom,
> 
> Thanks for reporting this.  I took another look at the MI code, and I
> suspect this patch might be the way to go:
> 
> ## START ##
> 
> diff --git a/gdb/testsuite/gdb.mi/mi-multi-commands.exp
> b/gdb/testsuite/gdb.mi/mi-multi-commands.exp
> index d00e0aaea8b..58187b15815 100644
> --- a/gdb/testsuite/gdb.mi/mi-multi-commands.exp
> +++ b/gdb/testsuite/gdb.mi/mi-multi-commands.exp
> @@ -100,7 +100,7 @@ proc run_test { args } {
>  	set seen_second_message false
>  
>  	gdb_test_multiple "" "look for first command output, command length $i"
> -prompt "$mi_gdb_prompt" {
> -	    -re "\\^done,value=\"\\\\\"FIRST COMMAND\\\\\"\"" {
> +	    -re "\\^done.*,value=\"\\\\\"FIRST COMMAND\\\\\"\"" {
>  		set seen_first_message true
>  		exp_continue
>  	    }
> 
> ## END ##
> 
> The problem is that the '^done' and the ',value="...."' are printed by two
> separate write calls, and so, depending on timing, it is possible that the
> terminal might choose to echo some output between these two write calls.
> 

I see, that makes sense.

> I don't think the same protection is needed for the "TEST COMPLETE" case
> (just below the hunk I patched above) as that message is from the second
> (and last command), thus by the time we are printing that we know there
> should be no additional incoming command text that might interrupt the
> command output.
> 

Ack, sounds reasonable.

> I tried a few times to reproduce the failure you are seeing (before
> patching) and was not successful.  If you can reproduce the failure more
> consistently, could you give this patch a go please and let me know if it
> fixes things.

For me it's not trivial to reproduce at this point, but I managed twice in an
(undisturbed, meaning afk) run of 100, like this:
...
$ for n in $(seq 1 100); do echo -n "$n: "; taskset -c 0 ./test.sh 2>&1 | grep
"expected passes"; cp gdb.log gdb.$n.log; done
...

Then, with your patch applied, I got clean results for all 100 runs.

So, LGTM.

-- 
You are receiving this mail because:
You are on the CC list for the bug.