On Tue 2021-09-21 21:30 , Jacob Bachmeyer wrote: > Martin Cermak wrote: > > Hi folks, > > > > running make check for dejagnu-1.6.3 on Fedora 34. I'm seeing > > test failures per attached runtest sum and log files. I'm > > wondering whether these issues are known. Looking at the open > > bug list, I don't seem to see a matching one. > > > > Thoughts? > > I was wondering how long it would take for Fedora to pick up the 1.6.3 > release... > > Back to the point, this is actually a bug in Expect 5.45.4 (and possibly > other versions) that is tracked as bug#49078 in the GNU debbugs instance > after the LinuxFromScratch people initially reported it: Expect is > incorrectly treating a line exactly 64 bytes long as EOF. > > I have been investigating the issue but have not yet tracked down the exact > cause or exactly where to go to push a fix upstream. Does Fedora have > someone sufficiently familiar with the Expect codebase and Tcl community to > get this fixed? > > My notes so far: > > An input line exactly 64 bytes long (64 bytes followed by newline) causes > exp_get_next_event in exp_event.c to return -9 (EXP_DATA_NEW) which > exp_interpreter in exp_main_sub.c incorrectly treats as EOF. This causes > Expect to exit, but somehow leaves the newline in the terminal buffer. If > Expect is run under GDB, the stray newline will be read and processed by > GDB, typically causing various mayhem; if GDB is attached from another > terminal, the stray newline will be read and processed by the shell after > Expect exits. > The issue does not occur if Expect's input is a pipe, only when the child > Expect is taking input from a pty. The input does not need to arrive in a > single burst and is unaffected by the basic *nix line editing; the issue > occurs when a line 64 bytes long is sent to the child Expect. This can also > be observed using ssh and/or xterm, as long as the Expect process is using a > pty.
Thank-you for the analysis, Jacob. Not sure about a community, but I've tried to spread the word. Martin
