Re: dialog --pause not timing out on serial console (dialog 1.2)

[Thomas Dickey]

On Wed, Jul 14, 2021 at 04:21:56PM +0300, Stefan Puiu wrote:
> Hi Thomas,
> 
> Sorry for resurrecting an old thread, but I dug a bit deeper into this
> and was wondering if the new info rings any bells.
> 
> On Thu, Jan 28, 2021 at 9:59 PM Thomas Dickey <dickey@his.com> wrote:
> >
> [...]
> > > > > We have dialog 1.2 (release 4.20130902.fc20) and ncurses 5.9 (release
> > > > > 12.20130511.fc20), I know, ancient stuff.
> > > >
> > > > yes, that's known and supposed to have been fixed.
> > > > This appears to be relevant:
> > > >
> > > > https://invisible-island.net/dialog/CHANGES.html#t20030818
> > > >         + better solution for initializing curses when "--stdout" 
> > > > option is
> > > >           used, e.g., use stderr for the output if it is a tty.  Also 
> > > > correct
> > > >           the error handling, so dialog exits with an error if it cannot
> > > >           find a way to do output (Debian #205509).
> > >
> > > Thanks for the pointer. I think that change is a bit old, though, the
> > > Fedora package seems to be from 2013, and from the look of the release
> > > tag (and the RPM changelog), I think it's based on
> > > dialog-1.2.20130902.
> >
> > agreed - I mentioned it because I didn't notice further change notes
> > for this issue (though I seem to recall some followup).
> 
> Somebody managed to reproduce this again, and this time I debugged
> dialog a bit with gdb, and it seems to be stuck inside a tcsetattr
> call:
> 
> (gdb) bt
> #0  0x0000003b96aeb5cc in __GI_tcsetattr (fd=1,
> optional_actions=optional_actions@entry=1,
>     termios_p=termios_p@entry=0x7fff17feba40) at
> ../sysdeps/unix/sysv/linux/tcsetattr.c:83
> #1  0x0000003b98e1677a in _nc_set_tty_mode
> (buf=buf@entry=0x7fff17feba40) at
> ../../ncurses/tinfo/lib_ttyflags.c:108
> #2  0x0000003b98e10d8c in cbreak () at ../../ncurses/tinfo/lib_raw.c:155
> #3  0x0000003b97214f33 in _nc_initscr () at 
> ../../ncurses/base/lib_newterm.c:79

hmm - ncurses kind of expects the system to return an error :-)

perhaps the serial I/O driver isn't that cooperative.

If that happened often enough, I'd have some code to do a sanity check
on "tty" to make sure the initialization wouldn't hang.

> #4  newterm (name=<optimized out>, ofp=<optimized out>, ifp=<optimized
> out>) at ../../ncurses/base/lib_newterm.c:332
> #5  0x0000003b97211343 in initscr () at ../../ncurses/base/lib_initscr.c:87
> #6  0x0000003e24225f5d in init_dialog (input=<optimized out>,
> output=0x3b96db81c0 <_IO_2_1_stderr_>) at util.c:385
> #7  0x0000000000402351 in main (argc=12, argv=0x7fff17fec638) at dialog.c:1844
> 
> (gdb) info locals
> resultvar = 18446744073709551104
> k_termios = {c_iflag = 21504, c_oflag = 5, c_cflag = 7346, c_lflag =
> 2105, c_line = 0 '\000',
>   c_cc = 
> "\003\034\177\025\004\000\001\000\021\023\032\000\022\017\027\026\000\000"}
> cmd = <optimized out>
> retval = <optimized out>
> 
> 
> As far as I can tell, it's trying to call ioctl 0x5043 (TCSETSW) on fd
> 1 (stdout), and that call blocks. Maybe the serial driver in the
> kernel is getting blocked on something? Any ideas?

ncurses asked isatty if stdout is a tty (and was told that it is),
so it tries using termios stuff to initialize it -- and apparently
gets nowhere

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature