From owner-freebsd-hackers Wed Apr 10 15:56:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA17204 for hackers-outgoing; Wed, 10 Apr 1996 15:56:35 -0700 (PDT) Received: from edna.bus.net (edna.bus.net [207.41.24.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA17199 for ; Wed, 10 Apr 1996 15:56:33 -0700 (PDT) Received: (from chuck@localhost) by edna.bus.net (8.6.12/8.6.12) id SAA03808; Wed, 10 Apr 1996 18:55:34 -0400 Date: Wed, 10 Apr 1996 18:55:34 -0400 (EDT) From: "Chuck O'Donnell" To: freebsd-hackers@freebsd.org Subject: Need help with possible fbsd bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Possible Bug Report: Submitted by: Chuck O'Donnell (chuck@bus.net), a FreeBSD user Hugh Redelmeier (hugh@mimosa.com), a JOVE author Symptom: In jove, when running an interactive shell in a buffer, pressing the return key repeats the command on the prompt line anywhere from 50 to 500 times. 1) run jove: $ jove 2) start up an interactive shell window within jove: ESC x shell RETURN [note: don't type the spaces] 3) issue a simple echo command in the window $ echo hi 4) observe the multiple outputs. Hypotheses: The pseudo tty driver is confused about the length of buffer contents. In particular, a write call on the pty returns 0, indicating a successful write of no characters; subsequent reads from the pty yield more characters than were written. Environment: OS: FreeBSD 2.1.0-RELEASE Computer: Intel pentium jove version: 4.16 (4.16beta is shipped with system and fails too) shell: bash (but fails with sh and csh too) Investigation and Analysis: We used ktrace to see what was going on. Here is how we did it, using two virtual terminals: on first terminal: start jove on second terminal: find out process id of jove process (ps & grep) ktrace -i -p -t cis [my *guess* at best flags to use] on first terminal: issue jove "shell" command in shell window, issue minor command like "echo hi" on second terminal, turn off tracing: ktrace -C The result was a large ktrace.out. Here is a chunk from the middle, with commentary: The first run of lines seems to be a character-at-a-time loop, reading from the keyboard (standard in: 0) and echoing the characters to the screen (standard out: 1). The select is just to determine that the next interesting event is a keystroke, or that the screen is ready. Here is the trace of a single cycle of this loop. 212 jove CALL select(0x4,0xefbfdcec,0,0,0) 212 jove RET select 1 212 jove CALL read(0,0x38a48,0x14) 212 jove GIO fd 0 read 1 bytes "h" 212 jove RET read 1 212 jove CALL select(0x1,0xefbfdcd0,0,0,0xefbfdcc8) 212 jove RET select 0 212 jove CALL write(0x1,0x3e800,0x1) 212 jove GIO fd 1 wrote 1 bytes "h" 212 jove RET write 1 When the \r is read, the fun begins: 212 jove CALL select(0x4,0xefbfdcec,0,0,0) 212 jove RET select 1 212 jove CALL read(0,0x38a48,0x14) 212 jove GIO fd 0 read 1 bytes "\r" 212 jove RET read 1 Here JOVE writes 8 bytes to the file descriptor 3, presumably the pty feeding bash. But wait: the result is very peculiar. (It is important to note that this is the first write to the pty; it must be empty before this.) 212 jove CALL write(0x3,0x3b316,0x8) 212 jove GIO fd 3 wrote 0 bytes "" Why does it appear as if 0 bytes were written, even though jove tried to write 8??? I look forward from here for the next line describing process 212 jove. It is very far forward, past all the I/O corresponding to the multiple echo commands that bash sees. It reads [later] 212 jove RET write 0 so jove is being told that the write was successful, but 0 bytes were written! Jove only checks whether the write was successful, and doesn't pay attention to the length reported by write. Jove will not retry this write, although that would be reasonable. 257 bash GIO fd 0 read 128 bytes "echo hi echo hi echo hi echo hi echo hi echo hi echo hi echo hi echo hi echo hi echo hi echo hi echo hi echo hi echo hi echo hi " 257 bash RET read 128/0x80 This is quite odd. Bash is getting 128 characters, containing multiple copies of what jove was unable to write!!! This read was issued by bash much earlier: [earlier] 257 bash CALL read(0,0x52058,0x8) << 0x80, 128 bytes Notice that the amount returned by the read was the length requested by bash. I think that a pty should return at most a line at a time, even if the read requested more. At this point, things are so very wrong we need not look farther in the trace. Is jove using the pty incorrectly? In particular, does the pty somehow need to be set up in a way different from what jove has done. Do streams modules need to be pushed? We think jove works fine on other BSD systems. It sure looks like there is a FreeBSD bug, but it might only be in ktrace/kdump. In particular, the pty write says that 0 bytes were written, but at least 128 bytes, some perhaps fictitious, are read. It is pretty clear that the 0 return is wrong, but depending on whether jove actually tried to repeat the write, the 128 bytes might be partially bogus too. Another interesting but unanalyzed observation: I tried running two kdump processes instead of one: one for bash and one for jove. The machine has crashed a twice while running i-shells, leading me to believe that maybe something is overloaded. A simple "echo something" command will complete (albeit multiple times), but a "ls" will sometimes lockup or reboot the machine. Can anyone offer any guidance here? We would appreciate some help. Thanks. Regards, Chuck O'Donnell, Hugh Redelmeier