Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1
Hello Thomas, On Tue, Mar 08, 2005 at 11:06:03AM -0500, Thomas Dickey wrote: On Tue, Mar 08, 2005 at 03:46:56PM +, Jochen Voss wrote: Hello Thomas, On Tue, Mar 08, 2005 at 10:20:14AM -0500, Thomas Dickey wrote: thanks. Actually I had forgotten the TCSETA detail, but noticed the hardware platform which seems to be relevant as well. Is the TCSETA ioctl documented in some publicly accessible place? For instance Solaris' termio manpage says this: TCSETA The argument is a pointer to a termio structure. Those terminal parameters that can be stored in a ter- mio structure are set from the values stored in that structure. The change is immediate. And do you know what it means to set the CS7 flag in c_cflags? The libc manual just sais This specifies seven bits per byte, which sounds like it should never be set on todays hardware? Maybe the call is perfectly right to return an error code for this setting? All the best, Jochen -- http://seehuhn.de/ signature.asc Description: Digital signature
Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1
On Sat, Mar 12, 2005 at 03:42:33PM +, Jochen Voss wrote: Hello Thomas, On Tue, Mar 08, 2005 at 11:06:03AM -0500, Thomas Dickey wrote: On Tue, Mar 08, 2005 at 03:46:56PM +, Jochen Voss wrote: Hello Thomas, On Tue, Mar 08, 2005 at 10:20:14AM -0500, Thomas Dickey wrote: thanks. Actually I had forgotten the TCSETA detail, but noticed the hardware platform which seems to be relevant as well. Is the TCSETA ioctl documented in some publicly accessible place? For instance Solaris' termio manpage says this: TCSETA The argument is a pointer to a termio structure. Those terminal parameters that can be stored in a ter- mio structure are set from the values stored in that structure. The change is immediate. And do you know what it means to set the CS7 flag in c_cflags? The 8th bit can be ignored in that case. By itself, that doesn't make it zero. Checking the termio manpage on Solaris (which is more complete than Linux's), we see If ISTRIP is set, valid input characters are first stripped to seven bits, otherwise all eight bits are processed. The libc manual just sais This specifies seven bits per byte, which sounds like it should never be set on todays hardware? Maybe the call is perfectly right to return an error code for this setting? Not exactly: it is redundant for xterm to set it in this case, but since the header files define it, it should be supported by the terminal driver (which is independent of the hardware). It's been a while since I noticed, but it used to be the case that 8-bit paths for telnet weren't guaranteed. For instance SunOS 4.x's telnet didn't do that. However, that's not the reason why I didn't change it. It was because the single resource setting eightBitInput does two functions (adding an ESC versus mapping meta+key to 128+key), so changing the CS7/CS8 setting wouldn't have affected the result. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpFAwTehSo5f.pgp Description: PGP signature
Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1
Package: xterm Version: 4.3.0.dfsg.1-12 Severity: normal Hello, on my shiny new Apple Powerbook G4 I encounter the problem described in (closed) bug #105874. The problem is the following: When I try to start xterm with eightBitInput set to false, I opens a window for a fraction of a second but then dies with the error message xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1 The problem goes away when I set eightBitInput to true. The problem did not occur when a virtually identical configuration was used on an i386 based system. My feeble debugging attempts could narrow down the source of the problem a little bit: the error message is caused by the following lines of code (xterm/main.c, lines 3547-3548): if (ioctl(ttyfd, TCSETA, tio) == -1) HsSysError(cp_pipe[1], ERROR_TIOCSETP); This is executed in the child process after the fork, and the error condition is reported back to the parent process via a pipe in an a little bit convoluted manner. Some information about my laptop can be found on my home page at http://seehuhn.de/comp/powerbook/ . If you need any further information please ask. I hope this helps, Jochen -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.11 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages xterm depends on: ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libexpat11.95.8-1XML parsing C library - runtime li ii libfontconfig1 2.2.3-4 generic font configuration library ii libfreetype6 2.1.7-2.3 FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-12 Inter-Client Exchange library ii libncurses5 5.4-4 Shared libraries for terminal hand ii libsm6 4.3.0.dfsg.1-12 X Window System Session Management ii libxaw7 4.3.0.dfsg.1-12 X Athena widget set library ii libxext6 4.3.0.dfsg.1-12 X Window System miscellaneous exte ii libxft2 2.1.2-6 FreeType-based font drawing librar ii libxmu6 4.3.0.dfsg.1-12 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-12 X pixmap library ii libxrender1 0.8.3-7 X Rendering Extension client libra ii libxt6 4.3.0.dfsg.1-12 X Toolkit Intrinsics ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu ii xlibs-data 4.3.0.dfsg.1-12 X Window System client data -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1
This is the same as #229566 -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpO2jx4CkWE8.pgp Description: PGP signature
Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1
Hello Thomas,
On Tue, Mar 08, 2005 at 10:20:14AM -0500, Thomas Dickey wrote:
thanks. Actually I had forgotten the TCSETA detail, but noticed the
hardware platform which seems to be relevant as well.
Is the TCSETA ioctl documented in some publicly accessible place?
Just for reference: In the failure case (eigthBitInput: false) the ioctl
argument is as follows.
(gdb) p tio
$1 = {c_iflag = 768, c_oflag = 3, c_cflag = 2575, c_lflag = 1487,
c_line = 0 '\0',
c_cc =
\003\034\177\025\004\001\000\000\000\000\027\022\032\021\023\026\017, '\0'
repeats 14 times, c_ispeed = 0, c_ospeed = 0}
The call returns -1 in this case and HsSysError is called.
If I set eigthBitInput: true, then the argument to ioctl is
(gdb) p tio
$1 = {c_iflag = 768, c_oflag = 3, c_cflag = 2831, c_lflag = 1487,
c_line = 0 '\0',
c_cc =
\003\034\177\025\004\001\000\000\000\000\027\022\032\021\023\026\017, '\0'
repeats 14 times, c_ispeed = 0, c_ospeed = 0}
(only difference: the c_cflag member has bit 9 set, which looks like
the switch from CS7 to CS8). This time the call succeeds.
Maybe its a kernel or libc bug after all?
All the best,
Jochen
PS.: I was unsure which bug report entry I should forward this
information to. I choose my copy of the bug report. Hope that this
is ok.
--
http://seehuhn.de/
signature.asc
Description: Digital signature
Bug#298551: xterm: fatal pty error 23 (errno=22) on tty /dev/pts/1
On Tue, Mar 08, 2005 at 03:46:56PM +, Jochen Voss wrote: Hello Thomas, On Tue, Mar 08, 2005 at 10:20:14AM -0500, Thomas Dickey wrote: thanks. Actually I had forgotten the TCSETA detail, but noticed the hardware platform which seems to be relevant as well. Is the TCSETA ioctl documented in some publicly accessible place? For instance Solaris' termio manpage says this: TCSETA The argument is a pointer to a termio structure. Those terminal parameters that can be stored in a ter- mio structure are set from the values stored in that structure. The change is immediate. Changing it to TCSETAF might change the behavior (mentioning this not to fix the problem, but to get more information about it). TCSETAF The argument is a pointer to a termio structure. Those terminal parameters that can be stored in a termio structure are set from the values stored in that structure. The change occurs after all characters queued for output have been transmitted; all charac- ters queued for input are discarded and then the change occurs. I have a hunch that TCSETAF is used in more applications, so a bug in the former might be overlooked. Maybe its a kernel or libc bug after all? I suspect that, but don't have an easy way to prove it. There are a couple of things that are related: Some time ago there were comments to the effect that the PowerPC port had changed some of the I/O structs incompatibly, causing some isolated failures. I mentioned that to Brandon when this bug came up, but his opinion was that those problems had been dealt with. The other is whether the connection is remote or local (I don't have the other report at hand, but seem to recall that this problem happens on local connections). All the best, Jochen PS.: I was unsure which bug report entry I should forward this information to. I choose my copy of the bug report. Hope that this is ok. that's fine (Brandon may merge them as he needs to). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp7MsAN3itYQ.pgp Description: PGP signature
