Re: Confirming X02zlevi test failures

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

"Jun T." wrote:
> If I commented out 'zpty_flush After zletest', then 2/1000 failed.
> Then I changed 'read -t 0.011' to 'read -t 0.02' and got 1000/1000 success.

One thing to be wary of when using the vi test is that there is no
counter test in there: we don't have a test of username completion on
\e~ with a suitable lack of delay between the two keystrokes.

If we can make it work, we should probably have two earlier tests
explicitly testing KEYTIMEOUT.

Bart wrote:
> I begin to suspect that what needs to happen is that zpty needs to be a
> lot more aggressive internally about consuming (and buffering up) the
> slave output as fast as it appears

I decided to see if I could reproduce the problem using expect. The
results somewhat convince me that tweaking zpty isn't going to help.
With expect it is easier to adjust the delays and parameters. But the
results aren't always making much sense, either on Linux or BSD. On
Linux, switching between precisely 1000 and 999 micro seconds was making
a difference. I've attached the expect script. The second parameter to
send_slow and -s option to send control the delays but other, seemingly
innocuous, changes can also make a difference.

> The second thing I found is that, possibly for the same reason, the
> delayzetterm flag is (inconsistently in terms of zletest input, but
> consistently for this particular test) getting set, which causes
> KEYTIMEOUT to be ignored.  The comment for delayzetterm says:

I've been looking at this too. I noticed instances where the
FIONREAD in getbyte() was returning 0, it then called zsetterm again
which does another FIONREAD ioctl but received a value of 5. There's an
unavoidable race condition if we can't stop more characters coming in
between the FIONREAD and the settyinfo. Even so, it seems a bit
pointless to do the ioctl twice. I've attached a patch to make getbyte
just call zsetterm again and rely on it trying the ioctl again. Not that
this helps us much.

Are you just using strategically placed dputs for instrumentation? I
seem to get nothing from them after the terminal has been configured.
truss/ltrace are not much use. dtrace is just hanging for me but I've
never tried it on BSD before. I'll try gdb with a command file. I've
just realised on reading the e-mail before sending that the dtrace
problem is because the prompt is # for root instead of the % that expect
is expecting. I couldn't find a way to enable it for a normal user on
BSD.

Oliver

diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c
index d157e36..a38f55b 100644
--- a/Src/Zle/zle_main.c
+++ b/Src/Zle/zle_main.c
@@ -238,9 +238,9 @@ zsetterm(void)
 	 * we can't set up the terminal for zle *at all* until
 	 * we are sure there is no more typeahead to come.  So
 	 * if there is typeahead, we set the flag delayzsetterm.
-	 * Then getbyte() performs another FIONREAD call; if that is
-	 * 0, we have finally used up all the typeahead, and it is
-	 * safe to alter the terminal, which we do at that point.
+	 * Then getbyte() calls here to performs another FIONREAD call;
+	 * if that is 0, we have finally used up all the typeahead, and
+	 * it is safe to alter the terminal, which we do at that point.
 	 */
 	delayzsetterm = 1;
 	return;
@@ -884,12 +884,8 @@ getbyte(long do_keytmout, int *timeout)
 	ret = STOUC(kungetbuf[--kungetct]);
     else {
 #ifdef FIONREAD
-	if (delayzsetterm) {
-	    int val;
-	    ioctl(SHTTY, FIONREAD, (char *)&val);
-	    if (!val)
-		zsetterm();
-	}
+	if (delayzsetterm)
+	    zsetterm();
 #endif
 	for (;;) {
 	    int q = queue_signal_level();

#<text/plain
#!/usr/local/bin/expect -f
set timeout -1
set send_slow { 1 .05 }
spawn -noecho -nottyinit -nottycopy inst/bin/zsh -f
expect %
send "bindkey -s '\\e~' user\r"
expect %
#send "KEYTIMEOUT=40\r"
#expect %
send -s ": o\033~\r"
expect {
    O { puts "\nswap case" }
    user { puts "\nusername completion" }
}
send "exit\r"