Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Oct 1998 15:40:01 -0800 (PST)
From:      Matthias Buelow <mkb@altair.mayn.de>
To:        freebsd-bugs@FreeBSD.ORG
Subject:   [patch] Re: bin/8438: ex/vi: Error: tcsetattr: Interrupted system call 
Message-ID:  <199810252340.PAA01270@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/8438; it has been noted by GNATS.

From: Matthias Buelow <mkb@altair.mayn.de>
To: robert+freebsd@cyrus.watson.org
Cc: freebsd-bugs@freebsd.org
Subject: [patch] Re: bin/8438: ex/vi: Error: tcsetattr: Interrupted system call 
Date: Sat, 24 Oct 1998 20:58:43 PDT

 "robert@fledge.watson.org" wrote:
 
 >>Number:         8438
 >>Category:       bin
 >>Synopsis:       ex/vi: Error: tcsetattr: Interrupted system call
 
 >3.0-BETA/RELEASE, using vi against a file in the local FFS file system
 >/usr.  X-windows using xterm, XiG's X server for notebooks.
 >
 >>Description:
 >
 >When resizing an xterm and using vi, once in a while I get:
 >
 >ex/vi: Error: tcsetattr: Interrupted system call
 >
 >This kills vi.  This is not good.  I believe I have observed this both
 >in command and edit modes.
 >
 >>How-To-Repeat:
 >
 >Start editing a file.  Now resize your xterm.  This does not always
 >appear to happen -- in fact, only infrequently.  I'm not sure if there
 >is a correspondence to the size of the file being edited.  I am unable
 >to repeat this consistently, but it has happened at least a few times 
 >in the past few months.
 >
 >>Fix:
 >	
 >I'm on the road, so can't check the source or see if there is already
 >a PR in for this.  However, I'd guess that something in curses/ncurses/
 >whatever vi uses doesn't wrap a syscall in a check for EINTR, and this
 >results in vi terminating from an error it does not expect.
 
 Yes, there're two occurrances of tcsetattr that are checked for errors,
 but EINTR is not taken care of.  It is quite trivial to do this.
 Keith Bostic (the author of nvi) is busy with db 2.x since 1996 (and
 doesn't seem to have time for fixing bugs), so you could try the following
 patch from a mere user (me :).  Please let me know if the problem goes
 away.  You could also try to get the source for 1.79 and build with the
 internal curses subset, instead of linking against FreeBSD libcurses
 (it is linked against the system's curses at least in 2.2.6 and 2.2.7;
 this is probably not the best idea, since the bundled curses is supposed
 to work best with it).
 
 
 --- cl/cl_screen.c.orig-1.79	Sun Oct 25 04:49:59 1998
 +++ cl/cl_screen.c	Sun Oct 25 04:50:54 1998
 @@ -368,6 +368,8 @@
  
  fast:	/* Set the terminal modes. */
  	if (tcsetattr(STDIN_FILENO, TCSASOFT | TCSADRAIN, &clp->vi_enter)) {
 +		if (EINTR == errno)
 +			goto fast;
  		msgq(sp, M_SYSERR, "tcsetattr");
  err:		(void)cl_vi_end(sp->gp);
  		return (1);
 @@ -486,6 +488,8 @@
  #endif
  
  fast:	if (tcsetattr(STDIN_FILENO, TCSADRAIN | TCSASOFT, &clp->ex_enter)) {
 +		if (EINTR == errno)
 +			goto fast;
  		msgq(sp, M_SYSERR, "tcsetattr");
  		return (1);
  	}
 
  - mkb
 
 To Unsubscribe: send mail to majordomo@FreeBSD.org
 with "unsubscribe freebsd-bugs" in the body of the message

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810252340.PAA01270>