Date: Wed, 10 Apr 1996 18:55:34 -0400 (EDT) From: "Chuck O'Donnell" <chuck@bus.net> To: freebsd-hackers@freebsd.org Subject: Need help with possible fbsd bug Message-ID: <Pine.BSF.3.91.960410184210.3535B-100000@edna.bus.net>
next in thread | raw e-mail | index | archive | help
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 <jovepid> -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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960410184210.3535B-100000>