Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
fixed in dialog 1.3 20200327 -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
On Fri, Mar 20, 2020 at 07:04:33PM -0400, Thomas Dickey wrote: ... > but want to see a test-case which produces the exit-code that was reported. never mind - I see it now. (however, I'm making a different change in this area) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
On Fri, Mar 20, 2020 at 08:04:36PM +, Rainer Weikusat wrote: > Thomas Dickey writes: > > From: Thomas Dickey > > Subject: Re: Bug#954220: dialog: program aborts on resize (not fixed by > > 1.3-20190808-1) > > To: Rainer Weikusat , 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 +, 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 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 (or any other non-terminal key, eg, 'a') => > program exits with an exit code of 255 (aka -1) [*]. ...but I'm not seeing the 255/-1, only 1. ...or if I do ./testi2 ...resize tab tab (back to "Ok") I get exit-code 0 (as expected). Either way, if I press 'a', I get a beep (as expected). I'm aware that performance would be better with blocking input (and have in the back of my mind that there are other wtimeouts which should perhaps be factored into this recovery-code), but want to see a test-case which produces the exit-code that was reported. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
Rainer Weikusat writes: [...] > Run > > dialog --yesno Text 0 0 > > resize window, press (or any other non-terminal key, eg, 'a') => > program exits with an exit code of 255 (aka -1) [*]. Addition: It's also possible to see that the program starts busy-waiting for key presses after the resize with top (or any other tool displaying CPU usage of a process).
Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
Thomas Dickey writes:
> From: Thomas Dickey
> Subject: Re: Bug#954220: dialog: program aborts on resize (not fixed by
> 1.3-20190808-1)
> To: Rainer Weikusat , 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 +, 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 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 (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 ). 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.
Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
On Wed, Mar 18, 2020 at 07:31:35PM +, 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. 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 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). The original test-case with msgbox also appears to work as expected. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net #!/bin/sh rm -f dialog.log export DIALOGOPTS="--trace dialog.log" dialog --msgbox Text 0 0 echo $? ** opened at Fri Mar 20 15:43:55 2020 ** dialog 1.3-20160828 # Parameters: # argv[0] = --trace # argv[1] = dialog.log # init_result # process_common_options, offset 0 # argv[0] = --trace # ignore extra --trace option # Parameters: # argv[0] = --trace # argv[1] = dialog.log # process_common_options, offset 1 # argv[1] = --msgbox # dlg_default_button() = 0 # dlg_register_window msgbox # key bindings for msgbox widgets bindkey msgbox ^E HELPFILE bindkey msgbox F1 HELPFILE bindkey msgbox HELP HELPFILE bindkey msgbox ^J ENTER bindkey msgbox ^M ENTER bindkey msgbox ENTER ENTER bindkey msgbox \s ENTER bindkey msgbox DOWN FIELD_NEXT bindkey msgbox RIGHT FIELD_NEXT bindkey msgbox ^I FIELD_NEXT bindkey msgbox UP FIELD_PREV bindkey msgbox BTAB FIELD_PREV bindkey msgbox LEFT FIELD_PREV bindkey msgbox DOWN GRID_DOWN bindkey msgbox UP GRID_UP bindkey msgbox HOME PAGE_FIRST bindkey msgbox END PAGE_LAST bindkey msgbox NPAGE PAGE_NEXT bindkey msgbox PPAGE PAGE_PREV bindkey msgbox J GRID_DOWN bindkey msgbox j GRID_DOWN bindkey msgbox K GRID_UP bindkey msgbox k GRID_UP bindkey msgbox g PAGE_FIRST bindkey msgbox G PAGE_LAST bindkey msgbox F PAGE_NEXT bindkey msgbox f PAGE_NEXT bindkey msgbox B PAGE_PREV bindkey msgbox b PAGE_PREV # mouse_mkregion 3,4 1x6 0 (10) # mouse_mkregion 3,4 1x6 0 (0) window 5x16 at 9,31 0:+--+ 1:| Text | 2:+--+ 3:| < OK > | 4:+--+ chr KEY_RESIZE (ch=0x19a, fkey=410) window 5x16 at 9,31 0:+--+ 1:| Text | 2:+--+ 3:| < OK > | 4:+--+ chr KEY_RESIZE (ch=0x19a, fkey=410) window 5x16 at 9,31 0:+--+ 1:| Text | 2:+--+ 3:| < OK > | 4:+--+ chr KEY_RESIZE (ch=0x19a, fkey=410) # mouse_mkregion 3,4 1x6 10 (10) # mouse_mkregion 3,4 1x6 0 (0) window 5x16 at 9,32 0:+--+ 1:| Text | 2:+--+ 3:| < OK > | 4:+--+ chr KEY_RESIZE (ch=0x19a, fkey=410) # mouse_mkregion 3,4 1x6 10 (10) # mouse_mkregion 3,4 1x6 0 (0) window 5x16 at 10,33 0:+--+ 1:| Text | 2:+--+ 3:| < OK > | 4:+--+ chr KEY_RESIZE (ch=0x19a, fkey=410) # mouse_mkregion 3,4 1x6 10 (10) # mouse_mkregion 3,4 1x6 0 (0) window 5x16 at 10,35 0:+--+ 1:| Text | 2:+--+ 3:| < OK > | 4:+--+ chr KEY_RESIZE (ch=0x19a, fkey=410) # mouse_mkregion 3,4 1x6 10 (10) # mouse_mkregion 3,4 1x6 0 (0) window 5x16 at 11,36 0:+--+ 1:| Text | 2:+--+ 3:| < OK > | 4:+--+ chr KEY_RESIZE (ch=0x19a, fkey=410) # mouse_mkregion 3,4 1x6 10 (10) # mouse_mkregion 3,4 1x6 0 (0) window 5x16 at 11,37 0:+--+ 1:| Text | 2:+--+ 3:| < OK > | 4:+--+ chr KEY_RESIZE (ch=0x19a, fkey=410) # mouse_mkregion 3,4 1x6 10 (10) # mouse_mkregion 3,4 1x6 0 (0) window 5x16 at 11,38 0:+--+ 1:| Text | 2:+--+ 3:| < OK > | 4:+--+ chr KEY_RESIZE (ch=0x19a, fkey=410) # mouse_mkregion 3,4 1x6 1
Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
petit conseil... garder votre attention sur le monde reel non sur le le
monde virtuel de l'internet ou des reseaux cabre. prenez conscience du
developpement et du denoument de la situation. et faite pas chier vos
voisin.
On 2020-03-18 8:24 p.m., Thomas Dickey wrote:
On Wed, Mar 18, 2020 at 07:31:35PM +, 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.
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
I overlooked that (was probably pressing the spacebar, which should exit).
This looks ok:
}
+wtimeout(win, -1);
dlg_trace_msg("# caught %d KEY_RESIZE key%s\n",
1 + caught,
caught == 1 ? "" : "s");
Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
wrong list sorry On 2020-03-18 10:33 p.m., Shayne wrote: etit conseil... garder votre attention sur le monde reel non sur le le monde virtuel de l'internet ou des reseaux cabre. prenez conscience du developpement et du denoument de la situation. et faite pas chier vos voisin.
Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
On Wed, Mar 18, 2020 at 07:31:35PM +, 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.
> 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
I overlooked that (was probably pressing the spacebar, which should exit).
This looks ok:
> }
> +wtimeout(win, -1);
> dlg_trace_msg("# caught %d KEY_RESIZE key%s\n",
> 1 + caught,
> caught == 1 ? "" : "s");
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
Santiago Vila writes: > Hi. > > I'm several releases behind at this point. > > Can you tell me if version 1.3-20191210 improves things in any way? > Pre-release here: > > https://people.debian.org/~sanvila/dialog/ I can tell you wgat I already told you. But please feel free to assume that industry-paid worktime is nothing but idot's musings.
Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
Hi. I'm several releases behind at this point. Can you tell me if version 1.3-20191210 improves things in any way? Pre-release here: https://people.debian.org/~sanvila/dialog/ Thanks.
Bug#954220: dialog: program aborts on resize (not fixed by 1.3-20190808-1)
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.
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 to switch from the yes- to the
no-button.
The attached patch fixes the issue by disabling the dlg_win_resize timeout
again before
returning from this function.
-- System Information:
Debian Release: 10.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-8-amd64 (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages dialog depends on:
ii debianutils 4.8.6.1
ii libc6 2.28-10
ii libncursesw6 6.1+20181013-2+deb10u2
ii libtinfo6 6.1+20181013-2+deb10u2
dialog recommends no packages.
dialog suggests no packages.
-- no debconf information
diff --git a/util.c b/util.c
index 64b67d9..6fa917e 100644
--- a/util.c
+++ b/util.c
@@ -2234,6 +2234,7 @@ dlg_will_resize(WINDOW *win)
}
}
}
+wtimeout(win, -1);
dlg_trace_msg("# caught %d KEY_RESIZE key%s\n",
1 + caught,
caught == 1 ? "" : "s");
