[PATCH] [gdb/testsuite] Fix gdb.tui/wrap-line.exp

[Tom de Vries]

On 5/21/23 10:51, Andrew Burgess wrote:
> Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
>> PR testsuite/30458 reports the following FAIL:
>> ...
>> PASS: gdb.tui/wrap-line.exp: width-auto-detected: cli: wrap
>> ^CQuit
>> (gdb) WARNING: timeout in accept_gdb_output
>> Screen Dump (size 50 columns x 24 rows, cursor at column 6, row 3):
>>      0 Quit
>>      1 (gdb) 7890123456789012345678901234567890123456789
>>      2 W^CQuit
>>      3 (gdb)
>>    ...
>> FAIL: gdb.tui/wrap-line.exp: width-auto-detected: cli: prompt after wrap
>> ...
>>
>> The problem is that the regexp doesn't account for the ^C:
>> ...
>>      gdb_assert { [Term::wait_for "^WQuit"] } "prompt after wrap"
>> ...
>>
>> Fix this by updating the regexp, and likewise in another place in the
>> test-case where we use ^C.
> 
> Do we know why we sometimes manage to see '^C'?  I guess it's a timing
> thing, but right now I'm at a loss for how we manage to see it.  It
> appears that we print the wrapping line, that ends with 'W', and then
> wait for this to be displayed.
> 
> At this point GDB should be in a stable state waiting in the
> event-loop.
> 
> When we send \003 this should trigger an event, which should trigger
> async_request_quit, which should result in the 'Quit' exception being
> thrown, caught, and printed.
> 
> I think the '^C' must be getting printed from tui_redisplay_readline
> maybe, but I can't see how that gets triggered with \003 in the input
> buffer.
> 
> I only ask because if we understand why '^C' is sometimes printed then
> we might be able to decide if this should always be printed, or never be
> printed, and change GDB accordingly...
> 

Hi Andrew,

yes, that's a good question.

[ Note that it's a TUI test-case, but the FAIL we're observing is in the 
cli part, before activating TUI, so tui_redisplay_readline has nothing 
to do with the FAIL. ]

I've added an assert in rl_echo_signal_char and managed to trigger it to 
generate a core file corresponding to the FAIL condition (more details 
in the PR).

My guess at what happens is the following:
- we send a W to gdb
- readline handles this, and echoes it
- after readline echoing it, expect notices this and we send a ^C to gdb
- at this point readline is still in the code handling the W, and
   handles the ^C by echoing it.

Usually, at this point we're already back in gdb and handle the ^C 
without echoing it.

Thanks,
- Tom

> Thanks,
> Andrew
> 
>>
>> Tested on x86_64-linux.
>>
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30458
>> ---
>>   gdb/testsuite/gdb.tui/wrap-line.exp | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/gdb/testsuite/gdb.tui/wrap-line.exp b/gdb/testsuite/gdb.tui/wrap-line.exp
>> index 4587517504c..2bfe342e04d 100644
>> --- a/gdb/testsuite/gdb.tui/wrap-line.exp
>> +++ b/gdb/testsuite/gdb.tui/wrap-line.exp
>> @@ -25,6 +25,8 @@ set cols 50
>>   set lines 24
>>   set dims [list $lines $cols]
>>   
>> +set re_control_c "(\\^C)?Quit"
>> +
>>   # Fill line, assuming we start after the gdb prompt.
>>   proc fill_line { width } {
>>       set res ""
>> @@ -47,7 +49,7 @@ proc fill_line { width } {
>>   proc test_wrap { wrap_width } {
>>       # Generate a prompt and parse it.
>>       send_gdb "\003"
>> -    gdb_assert { [Term::wait_for "(^|$::gdb_prompt )Quit"] } "start line"
>> +    gdb_assert { [Term::wait_for "(^|$::gdb_prompt )$::re_control_c"] } "start line"
>>   
>>       # Fill the line to just before wrapping.
>>       set str [fill_line $wrap_width]
>> @@ -64,7 +66,7 @@ proc test_wrap { wrap_width } {
>>   
>>       # Generate a prompt and parse it.
>>       send_gdb "\003"
>> -    gdb_assert { [Term::wait_for "^WQuit"] } "prompt after wrap"
>> +    gdb_assert { [Term::wait_for "^W$::re_control_c"] } "prompt after wrap"
>>   }
>>   
>>   # Test wrapping in both CLI and TUI.
>>
>> base-commit: 0cc8cc5e6f82b8d3d8e3803c6f7f5e63f0c866ad
>> -- 
>> 2.35.3
>