Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: error on TTY read: no such file or directory
- X-seq: zsh-workers 15907
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Zefram <zefram@xxxxxxxx>
- Subject: Re: error on TTY read: no such file or directory
- Date: Sun, 30 Sep 2001 02:23:16 +0000
- Cc: zsh-workers@xxxxxxxxxx
- In-reply-to: <20010930022055.B2654@xxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <3BB56D03.2000300@xxxxxxxxxxxxxx> <20010929034953.E16561@xxxxxxxxxxxxxx> <3BB62E93.10802@xxxxxxxxxxxxxx> <20010929170811.G16561@xxxxxxxxxxxxxx> <3BB63D16.5040709@xxxxxxxxxxxxxx> <20010929173848.H16561@xxxxxxxxxxxxxx> <3BB64378.8060505@xxxxxxxxxxxxxx> <20010929181100.I16561@xxxxxxxxxxxxxx> <1010929223918.ZM20169@xxxxxxxxxxxxxxxxxxxxxxx> <20010929202423.K16561@xxxxxxxxxxxxxx> <20010930022055.B2654@xxxxxxxx>
On Sep 30, 2:20am, Zefram wrote:
}
} The strace output you're getting shows the kernel violating the rules
} of the read() API; but if that may be broken, then it's also possible
} that ptrace() or strace is broken instead.
I don't think it's ptrace/strace that's broken, as the error output
that he's getting from zsh when not tracing is consistent with a > 1
return value from read().
I'd be suspicious that the kernel is expecting a 64-bit value as the
third argument to read() and is getting only a 32-bit value -- but in
that case I'd expect strace to show the whole 64 bits so that we'd be
able to tell how many bytes read() really was looking for; and that
would leave the question of where the other 1024 bytes came from, and
why stuffing 1025 bytes through the address of a single character on
the stack doesn't cause a more serious meltdown ...
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by:
Reverse Date,
Date,
Thread,
Author