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

[Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>]

On 5/21/23 18:48, Tom de Vries wrote:
> 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.
> 

Andrew, any comment?

Thanks,
- Tom

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