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

[Stefan Puiu]

Hi Stian,

On Thu, Jul 15, 2021 at 2:19 PM Stian Skjelstad
<stian.skjelstad@gmail.com> wrote:
>
> Hi Stefan
>
> I think that a log produced with strace (that shows the hang) would be 
> useful. If the bug is in a defective kernel API/driver, a bug-report there 
> will need some kind of usage report (and ideally a short test-code snippet)
>
> strace -o log myprogram myarguments

I'm afraid this isn't so easy to replicate; the situation happens once
in a while on a custom board that we make, with a peculiar serial
connection that I don't fully understand.

Also, the kernel and dialog/ncurses versions we use are rather old,
and upgrading isn't easy: this is a separate partition on a board that
is already shipped to customers. It's likely the kernel code changed a
bit since then. So I think the most I can hope for here is to a)
understand the bug (where in the kernel it's hanging), just in case we
hit something similar further down the road and b) find a good
workaround.

Thanks,
Stefan.

>
> Stian Skjelstad
>
>
> On Thu, Jul 15, 2021 at 9:29 AM Stefan Puiu <stefan.puiu@gmail.com> wrote:
>>
>> Hi Thomas,
>>
>> On Wed, Jul 14, 2021 at 11:37 PM Thomas Dickey <dickey@his.com> wrote:
>> [...]
>> > > 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.
>>
>> This hang doesn't seem to reproduce consistently, unfortunately. As
>> far as I can tell, most times dialog runs fine. Also, even when it
>> hangs, hooking up the serial console through software unblocks it. Is
>> there a way to find what is the serial driver used here? It would've
>> been good to have tried to print hung tasks using the magic sysrq key,
>> but it didn't occur to me to do that while the problem was reproduced.
>>
>> >
>> > > #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
>>
>> Sigh. Thanks for helping me make sense of this.
>>
>> Stefan.
>>