Thomas Dickey <dic...@his.com> writes:
> From: Thomas Dickey <dic...@his.com>
> Subject: Re: Bug#954220: dialog: program aborts on resize (not fixed by
> 1.3-20190808-1)
> To: Rainer Weikusat <rweiku...@cyberadapt.com>, 954...@bugs.debian.org
> Cc: sub...@bugs.debian.org
> Date: Fri, 20 Mar 2020 15:46:44 -0400 (7 minutes, 7 seconds ago)
> Reply-To: dic...@his.com
>
>
> On Wed, Mar 18, 2020 at 07:31:35PM +0000, Rainer Weikusat wrote:
>> Package: dialog
>> Version: 1.3-20190211-1
>> Severity: normal
>> Tags: patch
>>
>> As originally reported in #930775, the dialog program aborts with an exit
>> status of
>> 255 after resizing a widget. This is due to the dlg_win_resize function
>> (util.c)
>> configuring an input timeout of 0.02s which is then left in place, causing
>> the next
>> regular character read (via dlg_getc in ui_getc.c) to fail with a timeout
>> the code
>> isn't prepared to handle. The orignal command for triggering this was
>>
>> dialog --msgbox Text 0 0
>>
>> Supposedly, this issue is fixed in 1.3-20190808-1 but this isn't the case:
>> The relevant
>> change in there ignores getc errors after a resize until some key event is
>> received.
>
> I'm not seeing this behavior. In 20190724, I added
>
> wtimeout(win, 0);
>
> which conflicts with the suggested patch and leaves the input in nonblocking
> (rather than blocking) input.
Which is the exact problem: It means that the next input read will
immediately return with a timeout.
> 2019/07/24
> + modify dlg_will_resize() and dlg_result_key() functions to reduce
> the chance that dialog exits on a SIGWINCH (Debian #930775).
>
>> Because of this, the bug can no longer be triggered via msgbox as the only
>> key event
>> processed by that cause the program to exit. It's still possible to trigger
>> the issue
>> by using
>>
>> dialog --yesno Ohno 0 0
>>
>> resizing the window and then pressing <tab> to switch from the yes- to the
>> no-button.
>
> If I resize the window, the dialog doesn't exit by itself.
> Pressing either enter or space gives an exit-code 1 (which is
> expected).
I've just tested this with the most recent version: The behaviour is
exactly as described above:
Run
dialog --yesno Text 0 0
resize window, press <tab> (or any other non-terminal key, eg, 'a') =>
program exits with an exit code of 255 (aka -1) [*].
Replacing the
wtimeout(win, 0)
with
wtimeout(win, -1)
thus restoring blocking input, causes the issue to go away.
[*] This happens because the
if (dialog_state.had_resize) {
if (dialog_key == ERR) {
dialog_key = 0;
} else {
dialog_state.had_resize = FALSE;
}
} else if (fkey && dialog_key == KEY_RESIZE) {
dialog_state.had_resize = TRUE;
}
in dlg_result_key suppresses all errors until a non-resize event is seen
(eg, switching buttons with <tab>). As input is still nonblocking, the
next dlg_getc will very likely (if no other input is already available)
immediately return an error because of the timeout.
