On Fri, Mar 20, 2020 at 08:04:36PM +0000, Rainer Weikusat wrote: > 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) [*].
...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 <dic...@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
