From fenner@parc.xerox.com  Tue Apr  1 18:01:37 1997
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA25346
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 1 Apr 1997 18:01:35 -0800 (PST)
Received: from klute.parc.xerox.com ([13.2.116.207]) by alpha.xerox.com with SMTP id <58179(1)>; Tue, 1 Apr 1997 17:47:37 PST
Received: from sundae.parc.xerox.com ([13.2.117.33]) by klute.parc.xerox.com with SMTP id <59193>; Tue, 1 Apr 1997 14:45:46 PST
Received: (from fenner@localhost)
	by sundae.parc.xerox.com (8.8.5/8.8.5) id WAA05148;
	Tue, 1 Apr 1997 22:45:22 GMT
Message-Id: <199704012245.WAA05148@sundae.parc.xerox.com>
Date: Tue, 1 Apr 1997 14:45:22 PST
From: Bill Fenner <fenner@research.att.com>
Reply-To: fenner@research.att.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: vi freaks and dumps core if user doesn't exist
X-Send-Pr-Version: 3.2

>Number:         3170
>Category:       bin
>Synopsis:       vi(1): vi freaks and dump core if user doesn't exist
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Apr  1 18:10:02 PST 1997
>Closed-Date:    Sat Jul 28 19:52:29 UTC 2012
>Last-Modified:  Sat Jul 28 19:52:29 UTC 2012
>Originator:     Bill Fenner
>Release:        FreeBSD 2.2-RELEASE i386
>Organization:
Xerox
>Environment:

	
Stock 2.2-RELEASE install, running NIS with a Sun as an NIS server.

>Description:

	
I killed ypbind a while ago to test something and forgot to restart it.
I just started editing a file from mail and got:

+=+=+=+=+=+=+=+
Information on user id 5275 not found.
Modifications not recoverable if the session fails

then vi locked up for a while (possibly dumping core), and then
presumably exited since mail said:

Fatal error in process.
                       (continue)

(e.g. linefeed with no carraige return), and now doesn't accept normal
input.  I can't get any of the ~ commands to work, following either a
^M or ^L, but ^C^C did manage to get me out of mail.

vi clearly died at that point:

pid 4975 (vi), uid 5275: exited on signal 11

>How-To-Repeat:

	
I don't know if it's as simple as running yp, then killing ypbind and
editing a file.  I doubt it.

>Fix:
	
	
Unknown.
>Release-Note:
>Audit-Trail:

From: Bill Fenner <fenner@parc.xerox.com>
To: freebsd-gnats-submit@freebsd.org, fenner@parc.xerox.com, bostic@bostic.com
Cc:  Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Mon, 14 Apr 1997 13:48:08 PDT

 > How-To-Repeat
 > 
 >      I don't know if it's as simple as running yp, then killing ypbind >      and editing a file.  I doubt it.
 
 Surprise, surprise surprise.  It is sufficient.  Now I'm ashamed that
 I'm so lazy that I didn't try it until today =)
 
 The full how-to-repeat is:
 
 - Create a file owned by user foo
 - Remove user foo, either by having foo be in NIS and killing ypbind,
 or by editing the password file.
 - Edit the file owned by user foo
 - Move down a couple of lines (the dump sometimes doesn't happen if
 you don't do this)
 - Modify the file
 
 vi will die when it tries to warn you about the fact that the user
 doesn't exist so recovery won't work.
 
 I think the core dump is because we overran the stack.  vs_paint()
 appears to be involved in infinite recursion (which explains the
 delay before the core).  There are 74,879 instances of vs_paint() in
 the traceback; the rest is:
 
 #74879 0x3b9b7 in vs_paint (sp=0x4a000, flags=3)
     at /usr/src/usr.bin/vi/../../contrib/nvi/vi/vs_refresh.c:696
 #74880 0x3acb8 in vs_refresh (sp=0x4a000, forcepaint=1)
     at /usr/src/usr.bin/vi/../../contrib/nvi/vi/vs_refresh.c:119
 #74881 0x3206f in v_txt (sp=0x4a000, vp=0xefbfdb04, tm=0x0, lp=0x603d1
 "", 
     len=0, prompt=0, ai_line=3, rcount=1, flags=75793417)
     at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_txt.c:475
 #74882 0x2e156 in io (sp=0x4a000, vp=0xefbfdb04, cmd=o_cmd)
     at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_itxt.c:248
 #74883 0x2e018 in v_io (sp=0x4a000, vp=0xefbfdb04)
     at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_itxt.c:204
 #74884 0x373ee in vi (spp=0xefbfdbe4)
     at /usr/src/usr.bin/vi/../../contrib/nvi/vi/vi.c:235
 #74885 0xbbbe in editor (gp=0x48000, argc=2, argv=0xefbfdd5c)
     at /usr/src/usr.bin/vi/../../contrib/nvi/common/main.c:419
 #74886 0x2544 in main (argc=2, argv=0xefbfdd58)
     at /usr/src/usr.bin/vi/../../contrib/nvi/cl/cl_main.c:148
 
 vi does manage to display the
 
 +=+=+=+=+=+=+=+
 Information on user id 5275 not found.
 Modifications not recoverable if the session fails
 
 messages, but does not get to the point of "press enter to continue".
 I think that vi is trying to display the rest of the text here, but
 I don't know enough of its architecture to grok what is really
 happening.
 
   Bill
State-Changed-From-To: open->feedback 
State-Changed-By: joerg 
State-Changed-When: Sat Aug 23 16:14:57 MEST 1997 
State-Changed-Why:  

Bill, can you verify this still exists?  I don't have NIS here, but 
trying to remove a local user while he's logged in should have largely 
the same effect.  It didn't result in a coredump for me. 
State-Changed-From-To: feedback->open 
State-Changed-By: joerg 
State-Changed-When: Sat Aug 23 18:13:12 MEST 1997 
State-Changed-Why:  

Bill confirms problem exists still.  I can't reproduce it myself, 
so somebody else, please investigate. 

From: Daniel Hagan <dhagan@cs.vt.edu>
To: freebsd-gnats-submit@FreeBSD.org, fenner@parc.xerox.com
Cc:  
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Wed, 05 Apr 2000 21:09:15 -0400

 I tried this under 3.4-RELEASE with a bogus local user and couldn't
 recreate it.  If this still exists, is it tied to NIS somehow?
 
 Daniel
 
 

From: Anatoly Vorobey <mellon@pobox.com>
To: Daniel Hagan <dhagan@cs.vt.edu>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Thu, 6 Apr 2000 09:12:34 +0000

 On Wed, Apr 05, 2000 at 06:20:03PM -0700, Daniel Hagan wrote:
 > The following reply was made to PR bin/3170; it has been noted by GNATS.
 > 
 > From: Daniel Hagan <dhagan@cs.vt.edu>
 > To: freebsd-gnats-submit@FreeBSD.org, fenner@parc.xerox.com
 > Cc:  
 > Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
 > Date: Wed, 05 Apr 2000 21:09:15 -0400
 > 
 >  I tried this under 3.4-RELEASE with a bogus local user and couldn't
 >  recreate it.  If this still exists, is it tied to NIS somehow?
 
 FWIW, I succeeded in recreating this in -CURRENT a few weeks ago, but
 only once. I created a user, logged in as the user, created some files,
 logged in as root at the same time, removed the user, switched back
 to the user shell, tried to edit the files with vi. After I danced
 around a file and a bunch of lines, it freaked as described in the PR,
 but I couldn't reproduce it later. Apparently the bug is still there but
 triggered pretty randomly. No NIS whatsoever in my setup. 
 
 -- 
 Anatoly Vorobey,
 mellon@pobox.com http://pobox.com/~mellon/
 "Angels can fly because they take themselves lightly" - G.K.Chesterton
 

From: Daniel Hagan <dhagan@cs.vt.edu>
To: Anatoly Vorobey <mellon@pobox.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Thu, 6 Apr 2000 10:00:41 -0400 (EDT)

 On Thu, 6 Apr 2000, Anatoly Vorobey wrote:
 
 > FWIW, I succeeded in recreating this in -CURRENT a few weeks ago, but
 > only once. I created a user, logged in as the user, created some files,
 > logged in as root at the same time, removed the user, switched back
 > to the user shell, tried to edit the files with vi. After I danced
 > around a file and a bunch of lines, it freaked as described in the PR,
 > but I couldn't reproduce it later. Apparently the bug is still there but
 > triggered pretty randomly. No NIS whatsoever in my setup. 
 
 I didn't try this exact sequence.  I tried:
 
 1) Add bogus user
 2) login as bogus
 3) create file owned by bogus
 4) logout
 5) remove bogus from passwd files
 6) edit file as root
 
 I'll try your procedure sometime, which I understand was:
 
 1) Add bogus user
 2) login as bogus
 3) create file owned by bogus
 4) remove bogus from passwd files while bogus is still logged in
 5) edit file as bogus (who is still logged in)
 6) hopefully get core dump and recreate problem
 
 Daniel
 
 -- 
 Daniel Hagan                                             Computer Science CSE
 dhagan@cs.vt.edu                                http://www.cs.vt.edu/~dhagan/
 
 

From: Bill Fenner <fenner@research.att.com>
To: dhagan@cs.vt.edu
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Sat, 8 Apr 2000 20:08:08 -0700

 I'm able to replicate it using the same ol' steps on a month-old 4.0-CURRENT:
 
 1. log in as user foo
 2. vi a file
 3. ^Z vi
 4. su
 5. vipw, change user foo's uid (or delete user foo)
 6. suspend the su
 7. fg the vi
 8. make a change; vi says:
 +=+=+=+=+=+=+=+
 Information on user id 1000 not found.  
 Modifications not recoverable if the session fails
 Segmentation fault (core dumped)
 
 (which is not surprising, since vi hasn't changed since 1996)
 
   Bill
 

From: Bill Fenner <fenner@research.att.com>
To: mellon@pobox.com
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Thu, 13 Apr 2000 00:47:07 -0700

 vi must be running while you delete the user.  i.e. user exists, runs
 vi on an existing file (but don't make changes), delete user, make a
 change, vi dies.
 
   Bill
 

From: Anatoly Vorobey <mellon@pobox.com>
To: Bill Fenner <fenner@research.att.com>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Thu, 20 Apr 2000 02:13:26 +0000

 I've tracked down the bug to a fundamental conflict between vi's
 refresh engine and its warning display engine. The reason "deleted user"
 is at all relevant for reproducing the bug is that vi in that case tries
 to display two warnings at once (about nonexistent user and about
 impossibility of recovering the file in case of failure). In such a case,
 vi will want to prompt user with "Press a key to continue" and until
 it does, it won't refresh the screen; but if this whole condition was
 caused by a multiple-chars key (such as Up, mapped to Esc-something),
 then it also won't display the prompt until the rest of the chars in
 the buffer are processed, and to do that it needs to refresh the screen.
 Hence, a deadlock. The bug is there in all nvi versions including the
 latest one.
 
 That was a tricky bastard. I've no idea how to fix it though, the refresh
 code is a living nightmare and several of straightforward attempts were
 to no avail. I attach for the reference a message I sent to the maintainer
 a few days ago.
 
 Date: Mon, 17 Apr 2000 01:08:45 +0000
 From: Anatoly Vorobey <mellon@pobox.com>
 To: bostic@bostic.com
 Subject: an nvi bug
 
 Dear Keith,
 
 I've been trying to find the bug which apparently has been in nvi
 for quite some time, and is currently manifestable e.g. in all
 versions of FreeBSD (I work with -CURRENT). Although FreeBSD uses
 an old version, I just verified that the bug is still there in 1.79.
 
 There's some description of how to repeat the bug at
 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/3170 ; and see also
 below for more exact reproduction which never fails.
 
 Reproduction:
     Create a user, login as the user, delete the user with vipw(1)
     while the user stays logged in. Now the user goes into vi and
     tries to edit a small file with several rows (I used his default
     ~/.login_conf, for example). Immediately after invoking vi with
     the filename at command line, the user presses 'i', then preses
     Enter until all but the first line of the file have scrolled 
     down and the first line is on the last screen row, and at that
     moment he presses the Up key. vi tried to display the warning
     about nonexistent user and impossibility of recovering the file,
     freaks, hangs and eventually dumps core.
 
     On the other hand, if instead of the Up key you simply press Esc,
     vi successfully displays the warning, lets you press a key to 
     continue and goes on fine.
 
 I think I've found what the reason is, but I don't know the best way
 to fix the bug, hence this letter.
 
 The fact that the user has been deleted is only relevant insomuch as
 vi tries to present two-line warning (two separate warnings in fact)
 with calls to msgq(). The warnings come from rcv_init() and rcv_mailfile(),
 and rcv_init() is called from bd_set() which is the first function
 to be called by txt_resolve() in order to finally assimilate the inputed
 text into the file (it's followed by a bunch of bd_append()'s which are
 irrelevant).
 
 Now when the user pressed the Up key, the first character to register
 was Escape, with more mapped ones on the way. Escape triggered 
 txt_resolve() and eventual exit from the 'insert' function in v_itxt.c
 which was working all along till now since we started by Inserting.
 As the control goes one more time through the main loop of vi.c, we
 see:
 
                 /* Resolve messages. */ 
                 if (!MAPPED_KEYS_WAITING(sp) && vs_resolve(sp, NULL, 0)) 
                         goto ret; 
                  
                 /* 
                  * If not skipping a refresh, return to command mode and 
                  * refresh the screen. 
                  */ 
                 if (F_ISSET(vip, VIP_S_REFRESH)) 
                         F_CLR(vip, VIP_S_REFRESH); 
                 else  { 
                         sp->showmode = SM_COMMAND; 
                         if (vs_refresh(sp, 0)) 
                                 goto ret; 
                 } 
 
 Now when the user was pressing Escape, the !MAPPED_KEYS_WAITING 
 condition succeeded and vs_resolve() was called, which called
 vs_scroll(), and the latter displayed the "press any key" line
 and after pressing a key cleared up the two lines of scrolled
 warnings that were still there.
 
 But with a mapped key such as Up, the condition fails, and the control
 goes straight to vs_refresh(). Maybe vs_refresh() should be denied
 running until all remaining chars keys have been processed? I am not
 sure. Anyway, vs_refresh() goes to vs_paint() and only asks it to
 UPDATE_CURSOR. vs_paint() eventually needs to call vs_line() to find
 out where the cursor is. But in the beginning of vs_line():
 
         /*                                         
          * If ex modifies the screen after ex output is already on the 
 	 * screen\
          * don't touch it -- we'll get scrolling wrong, at best. 
          */ 
         if (!F_ISSET(sp, SC_TINPUT_INFO) && VIP(sp)->totalcount > 1) 
                 return (0); 
         if (F_ISSET(sp, SC_SCR_EXWROTE) && smp - HMAP != LASTLINE(sp)) 
                 return (0);                       
 
 
 The first test succeeds, since totalcount *is* >1 as we have two
 warnings pending on the screen -- and vs_line() immediately returns.
 vs_paint() freaks and calls itself recursively with the same flags,
 and we have an infinite recursion which gives way to the dump core when
 the stack is exhausted.
 
 That's it. In the case of Escape key, vs_resolve() had been called
 earlier and cleared totalcount, so the test fails and vs_line()
 dutifully does its work. However, one obviously can't introduce a call to
 vs_resolve() before the mapped characters have been processed.
 
 So I don't know exactly how to handle this best; the source of vs_paint()
 and friends is too complicated for me. Hopefully you'll know what to
 do with it, and please drop a line if you do so that I could submit
 a patch to the FreeBSD tree as well.
 
 Thanks,
 and all the best,
 Anatoly.
 
 -- 
 Anatoly Vorobey,
 mellon@pobox.com http://pobox.com/~mellon/
 "Angels can fly because they take themselves lightly" - G.K.Chesterton
 
 
 
 -- 
 Anatoly Vorobey,
 mellon@pobox.com http://pobox.com/~mellon/
 "Angels can fly because they take themselves lightly" - G.K.Chesterton
 
State-Changed-From-To: open->analyzed 
State-Changed-By: imp 
State-Changed-When: Wed Jun 13 13:20:36 MDT 2001 
State-Changed-Why:  
This bug is well analyzed, so transition its state from open to that state. 

It still happens on a -current system as of June 8th. 


http://www.FreeBSD.org/cgi/query-pr.cgi?pr=3170 

From: "Alexey V. Neyman" <alex.neyman@auriga.ru>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Wed, 23 Jan 2002 00:26:35 +0300

 Adding to Audit-Trail.
 The patch below solves the problem.
 
 ----------  Forwarded Message  ----------
 Subject: Re: :set leftright fix? (FreeBSD PR 26869)
 Date: Tue, 22 Jan 2002 22:05:27 +0100
 From: Sven Verdoolaege <skimo@kotnet.org>
 To: "Alexey V. Neyman" <alex.neyman@auriga.ru>
 
 Can you reproduce this in 1.81.5 ?
 If not, then maybe this patch (which is in 1.81.5) will help:
 
 Index: vs_line.c
 ===================================================================
 RCS file: /b/CVSROOT/vi/vi/vs_line.c,v
 retrieving revision 10.32
 retrieving revision 10.33
 diff -u -r10.32 -r10.33
 --- vs_line.c	2001/04/27 19:57:33	10.32
 +++ vs_line.c	2001/05/10 19:25:49	10.33
 @@ -10,7 +10,7 @@
  #include "config.h"
  
  #ifndef lint
 -static const char sccsid[] = "$Id: vs_line.c,v 10.32 2001/04/27 
 19:57:33 skimo Exp $ (Berkeley) $Date: 2001/04/27 19:57:33 $";
 +static const char sccsid[] = "$Id: vs_line.c,v 10.33 2001/05/10 
 19:25:49 skimo Exp $ (Berkeley) $Date: 2001/05/10 19:25:49 $";
  #endif /* not lint */
  
  #include <sys/types.h>
 @@ -49,7 +49,7 @@
  	size_t chlen, cno_cnt, cols_per_screen, len, nlen;
  	size_t offset_in_char, offset_in_line, oldx, oldy;
  	size_t scno, skip_cols, skip_screens;
 -	int dne, is_cached, is_partial, is_tab;
 +	int dne, is_cached, is_partial, is_tab, no_draw;
  	int list_tab, list_dollar;
  	CHAR_T *p;
  	CHAR_T *cbp, *ecbp, cbuf[128];
 @@ -63,10 +63,11 @@
  	 * If ex modifies the screen after ex output is already on the screen,
  	 * don't touch it -- we'll get scrolling wrong, at best.
  	 */
 +	no_draw = 0;
  	if (!F_ISSET(sp, SC_TINPUT_INFO) && VIP(sp)->totalcount > 1)
 -		return (0);
 +		no_draw = 1;
  	if (F_ISSET(sp, SC_SCR_EXWROTE) && smp - HMAP != LASTLINE(sp))
 -		return (0);
 +		no_draw = 1;
  
  	/*
  	 * Assume that, if the cache entry for the line is filled in, the
 @@ -75,7 +76,7 @@
  	 * cursor position, we can just return.
  	 */
  	is_cached = SMAP_CACHE(smp);
 -	if (yp == NULL && is_cached)
 +	if (yp == NULL && (is_cached || no_draw))
  		return (0);
  
  	/*
 @@ -160,7 +161,7 @@
  		}
  
  		/* If the line is on the screen, quit. */
 -		if (is_cached)
 +		if (is_cached || no_draw)
  			goto ret1;
  
  		/* Set line cache information. */
 @@ -324,7 +325,7 @@
  	    offset_in_line + cols_per_screen < sp->cno) {
  		cno_cnt = 0;
  		/* If the line is on the screen, quit. */
 -		if (is_cached)
 +		if (is_cached || no_draw)
  			goto ret1;
  	} else
  		cno_cnt = (sp->cno - offset_in_line) + 1;
 @@ -391,12 +392,12 @@
  				*xp += O_NUMBER_LENGTH;
  
  			/* If the line is on the screen, quit. */
 -			if (is_cached)
 +			if (is_cached || no_draw)
  				goto ret1;
  		}
  
  		/* If the line is on the screen, don't display anything. */
 -		if (is_cached)
 +		if (is_cached || no_draw)
  			continue;
  
  #define	FLUSH {								\
 
 skimo
Responsible-Changed-From-To: freebsd-bugs->sheldonh 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Thu Jan 31 05:59:18 PST 2002 
Responsible-Changed-Why:  
I'll tke this one, now that Alex has shown us a patch from the 
maintainer. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=3170 

From: Sheldon Hearn <sheldonh@starjuice.net>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: bin/3170: warning / refresh deadlock
Date: Thu, 31 Jan 2002 16:28:38 +0200

 I've committed the vendor's patch to -CURRENT and plan to merge it into
 -STABLE in a month.  Thus the PR remains in 'analyzed' state.
 
 Ciao,
 Sheldon.

From: Bill Fenner <fenner@research.att.com>
To: freebsd-gnats-submit@FreeBSD.org, fenner@research.att.com
Cc:  
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 19 Feb 2002 17:11:42 -0800

 Although vi no longer dumps core when this situation occurs, the message
 output is not correct, and the editing session behaves quite
 unpredictably.  When I do the experiment, vi now displays the following
 3 lines and hangs waiting for input:
 
 +=+=+=+=+=+=+=+
 Information on user id 639 not found.
  
 
 (yes, 3 lines -- the bottom line of the screen is blank).
 If I hit enter, it then says
 
 Press any key to continue:
 
 and the editing session proceeds with the screen in an inconsistent
 state, with the next input character causing multiple things to occur.
 
 I'm not convinced this is an improvement.  At least with the core dump,
 you're not going to do unexpected things to your file.  Please don't
 close this PR.

From: Bill Fenner <fenner@research.att.com>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 19 Feb 2002 17:50:59 -0800 (PST)

 more detail on the behavior on -current (FreeBSD stash.attlabs.att.com 5.0-CURRENT FreeBSD 5.0-CURRENT #70: Fri Feb 15 19:55:33 PST 2002     fenner@stash.attlabs.att.com:/usr/obj/usr/src/sys/STASHNOV6  i386):
 I created a file with "line 1" through "line 25".
 
 typed "O" at the top of file, screen looks like:
 
 vvvvv
 line 1
 line 2
 line 3
 line 4
 line 5
 line 6
 line 7
 line 8
 line 9
 line 10
 line 11
 line 12
 line 13
 line 14
 line 15
 line 16
 line 17
 line 18
 line 19
 line 20
 line 21
 +=+=+=+=+=+=+=+
 Information on user id 639 not found.
 
 ^^^^^
 
 Hit space, since it looks like it's waiting for a key.
 
 screen looks like:
 
 vvvvv
 line 1
 line 2
 line 3
 line 4
 line 5
 line 6
 line 7
 line 8
 line 9
 line 10
 line 11
 line 12
 line 13
 line 14
 line 15
 line 16
 line 17
 line 18
 line 19
 line 20
 +=+=+=+=+=+=+=+
 Information on user id 639 not found.
 
 Press any key to continue: 
 ^^^^^
 
 I press any key to continue, now the space looks like it was taken
 as a movement, since the cursor is on the "i" of "line 1".
 
 if I type "foo", the screen now looks like
 ("line 1" disappeared as soon as I typed the "f")
 
 vvvvv
  foo
 line 2
 line 3
 line 4
 line 5
 line 6
 line 7
 line 8
 line 9
 line 10
 line 11
 line 12
 line 13
 line 14
 line 15
 line 16
 line 17
 line 18
 line 19
 line 19
 line 20
 line 21
 line 22
 
 ^^^^
 
 and line 1 is missing from the screen.  Also note two copies of "line 19".
 
 Saving the file results in a file which has
 
 vvvvvv
 stash% cat /tmp/test
  foo
 line 1
 line 2
 line 3
 line 4
 line 5
 line 6
 line 7
 line 8
 line 9
 line 10
 line 11
 line 12
 line 13
 line 14
 line 15
 line 16
 line 17
 line 18
 line 19
 line 20
 line 21
 line 22
 line 23
 line 24
 line 25
 ^^^^^
 
 typescript of this session:
 
 begin 664 typescript
 M4V-R:7!T('-T87)T960@;VX@5'5E($9E8B`Q.2`Q-SHQ-#HS,R`R,#`R"G-T
 M87-H)2!V:2`O=&UP+W1E<W0-#0H;6S$[,C1R&UMM&UL_-V@;6S\Q:!L]&UM(
 M&UM*;&EN92`Q#1M;0FQI;F4@,@T;6T)L:6YE(#,-&UM";&EN92`T#1M;0FQI
 M;F4@-0T;6T)L:6YE(#8-&UM";&EN92`W#1M;0FQI;F4@.`T;6T)L:6YE(#D-
 M&UM";&EN92`Q,`T;6T)L:6YE(#$Q#1M;0FQI;F4@,3(-&UM";&EN92`Q,PT;
 M6T)L:6YE(#$T#1M;0FQI;F4@,34-&UM";&EN92`Q-@T;6T)L:6YE(#$W#1M;
 M0FQI;F4@,3@-&UM";&EN92`Q.0T;6T)L:6YE(#(P#1M;0FQI;F4@,C$-&UM"
 M;&EN92`R,@T;6T)L:6YE(#(S&UM(&ULR,T(O=&UP+W1E<W0Z('5N;6]D:69I
 M960Z(&QI;F4@,1M;2!M;,C-"&ULW;4EN9F]R;6%T:6]N(&]N('5S97(@:60@
 M-C,Y(&YO="!F;W5N9!M;2!M;;1M;,C%"&ULW;2L]*STK/2L]*STK/2L]*PT;
 M6T));F9O<FUA=&EO;B!O;B!U<V5R(&ED(#8S.2!N;W0@9F]U;F0N#1M;0DUO
 M9&EF:6-A=&EO;G,@;F]T(')E8V]V97)A8FQE(&EF('1H92!S97-S:6]N(&9A
 M:6QS&UM(&UMM&ULR,T(;6TL;6T@;6S(P0AM;31M;,T)0<F5S<R!A;GD@:V5Y
 M('1O(&-O;G1I;G5E.B`;6S$Y.S(R<AM;,3D[,4@;31M;,3LR-'(;6S$Y.S%(
 M;&EN92`Q.0T;6S-";&EN92`R,1M;2PT;6T)L:6YE(#(R#1M;0AM;2QM;2&P(
 M(&8;6TMO;P@;6T@;6TH@9F]O#1M;0FQI;F4@,@T;6T)L:6YE(#,-&UM";&EN
 M92`T#1M;0FQI;F4@-0T;6T)L:6YE(#8-&UM";&EN92`W#1M;0FQI;F4@.`T;
 M6T)L:6YE(#D-&UM";&EN92`Q,`T;6T)L:6YE(#$Q#1M;0FQI;F4@,3(-&UM"
 M;&EN92`Q,PT;6T)L:6YE(#$T#1M;0FQI;F4@,34-&UM";&EN92`Q-@T;6T)L
 M:6YE(#$W#1M;0FQI;F4@,3@-&UM";&EN92`Q.0T;6T)L:6YE(#$Y#1M;0FQI
 M;F4@,C`-&UM";&EN92`R,0T;6T)L:6YE(#(R&UM((&9O&UM(&UM*(&9O;PT;
 M6T)L:6YE(#(-&UM";&EN92`S#1M;0FQI;F4@-`T;6T)L:6YE(#4-&UM";&EN
 M92`V#1M;0FQI;F4@-PT;6T)L:6YE(#@-&UM";&EN92`Y#1M;0FQI;F4@,3`-
 M&UM";&EN92`Q,0T;6T)L:6YE(#$R#1M;0FQI;F4@,3,-&UM";&EN92`Q-`T;
 M6T)L:6YE(#$U#1M;0FQI;F4@,38-&UM";&EN92`Q-PT;6T)L:6YE(#$X#1M;
 M0FQI;F4@,3D-&UM";&EN92`Q.0T;6T)L:6YE(#(P#1M;0FQI;F4@,C$-&UM"
 M;&EN92`R,AM;2"!F;QM;2!M;2B!F;V\-&UM";&EN92`R#1M;0FQI;F4@,PT;
 M6T)L:6YE(#0-&UM";&EN92`U#1M;0FQI;F4@-@T;6T)L:6YE(#<-&UM";&EN
 M92`X#1M;0FQI;F4@.0T;6T)L:6YE(#$P#1M;0FQI;F4@,3$-&UM";&EN92`Q
 M,@T;6T)L:6YE(#$S#1M;0FQI;F4@,30-&UM";&EN92`Q-0T;6T)L:6YE(#$V
 M#1M;0FQI;F4@,3<-&UM";&EN92`Q.`T;6T)L:6YE(#$Y#1M;0FQI;F4@,3D-
 M&UM";&EN92`R,`T;6T)L:6YE(#(Q#1M;0FQI;F4@,C(;6T@@9F\;6T@;6TH@
 M9F]O#1M;0FQI;F4@,@T;6T)L:6YE(#,-&UM";&EN92`T#1M;0FQI;F4@-0T;
 M6T)L:6YE(#8-&UM";&EN92`W#1M;0FQI;F4@.`T;6T)L:6YE(#D-&UM";&EN
 M92`Q,`T;6T)L:6YE(#$Q#1M;0FQI;F4@,3(-&UM";&EN92`Q,PT;6T)L:6YE
 M(#$T#1M;0FQI;F4@,34-&UM";&EN92`Q-@T;6T)L:6YE(#$W#1M;0FQI;F4@
 M,3@-&UM";&EN92`Q.0T;6T)L:6YE(#$Y#1M;0FQI;F4@,C`-&UM";&EN92`R
 M,0T;6T)L:6YE(#(R&UM((&9O&UM(&UM*(&9O;PT;6T)L:6YE(#(-&UM";&EN
 M92`S#1M;0FQI;F4@-`T;6T)L:6YE(#4-&UM";&EN92`V#1M;0FQI;F4@-PT;
 M6T)L:6YE(#@-&UM";&EN92`Y#1M;0FQI;F4@,3`-&UM";&EN92`Q,0T;6T)L
 M:6YE(#$R#1M;0FQI;F4@,3,-&UM";&EN92`Q-`T;6T)L:6YE(#$U#1M;0FQI
 M;F4@,38-&UM";&EN92`Q-PT;6T)L:6YE(#$X#1M;0FQI;F4@,3D-&UM";&EN
 M92`Q.0T;6T)L:6YE(#(P#1M;0FQI;F4@,C$-&UM";&EN92`R,AM;2"!F;P<'
 M&UM"&UM"&UM!&UM!!P<;6T(;6T(;6T(;6T(;6T(;6T(;6T(;6T(;6T(;6T(;
 M6T(;6T(;6T(;6T(;6T(;6T(;6T(;6T(;6T@;6S--&ULR,$)L:6YE(#(S#1M;
 M0FQI;F4@,C0-&UM";&EN92`R-0T'&UM(&UM*;&EN92`T#1M;0FQI;F4@-0T;
 M6T)L:6YE(#8-&UM";&EN92`W#1M;0FQI;F4@.`T;6T)L:6YE(#D-&UM";&EN
 M92`Q,`T;6T)L:6YE(#$Q#1M;0FQI;F4@,3(-&UM";&EN92`Q,PT;6T)L:6YE
 M(#$T#1M;0FQI;F4@,34-&UM";&EN92`Q-@T;6T)L:6YE(#$W#1M;0FQI;F4@
 M,3@-&UM";&EN92`Q.0T;6T)L:6YE(#$Y#1M;0FQI;F4@,C`-&UM";&EN92`R
 M,0T;6T)L:6YE(#(R#1M;0FQI;F4@,C,-&UM";&EN92`R-`T;6T)L:6YE(#(U
 M#1M;2!M;2FQI;F4@-`T;6T)L:6YE(#4-&UM";&EN92`V#1M;0FQI;F4@-PT;
 M6T)L:6YE(#@-&UM";&EN92`Y#1M;0FQI;F4@,3`-&UM";&EN92`Q,0T;6T)L
 M:6YE(#$R#1M;0FQI;F4@,3,-&UM";&EN92`Q-`T;6T)L:6YE(#$U#1M;0FQI
 M;F4@,38-&UM";&EN92`Q-PT;6T)L:6YE(#$X#1M;0FQI;F4@,3D-&UM";&EN
 M92`Q.0T;6T)L:6YE(#(P#1M;0FQI;F4@,C$-&UM";&EN92`R,@T;6T)L:6YE
 M(#(S#1M;0FQI;F4@,C0-&UM";&EN92`R-0T;6S$[,C-R&ULQ.S%(&ULS3!M;
 M,3LR-'(;6S$[,DAF;V\-&UM";&EN92`Q#1M;0FQI;F4@,@T;6S$Q0AM;2!M;
 M0AM;02`'&ULR,T((+W1M<"]T97-T.B!M;V1I9FEE9#H@;&EN92`Q(&]F(#(V
 M(%LS)5T;6T@@"!M;,TT;6S(P0FQI;F4@,C,;6TL-&UM";&EN92`R-`T;6T)L
 M:6YE(#(U&ULQ.3LQ2!M;-$(;6S$[,C-R&ULQ.S%(&ULS3!M;,3LR-'(;6S$[
 M,DAF;V\-&UM";&EN92`Q#1M;0FQI;F4@,@T;6S$Q0AM;2!M;0AM;02`;6S(S
 M0@@;6S=M57-A9V4Z(%I:&UM(&UM#&UMM!QM;,C-""!M;/S%L&SX;6S(T.S%(
 M#1M;/S%L&SX-"E-U<W!E;F1E9`T*<W1A<V@E(&QE<W,@+W1M<"]T97-T(`T-
 M"AM;/S%H&ST;6S(T.S%(&UM+;&EN92`Q#0IL:6YE(#(-"FQI;F4@,PT*;&EN
 M92`T#0IL:6YE(#4-"FQI;F4@-@T*;&EN92`W#0IL:6YE(#@-"FQI;F4@.0T*
 M;&EN92`Q,`T*;&EN92`Q,0T*;&EN92`Q,@T*;&EN92`Q,PT*;&EN92`Q-`T*
 M;&EN92`Q-0T*;&EN92`Q-@T*;&EN92`Q-PT*;&EN92`Q.`T*;&EN92`Q.0T*
 M;&EN92`R,`T*;&EN92`R,0T*;&EN92`R,@T*;&EN92`R,PT*&ULR-#LQ2!M;
 M2QM;-VTO=&UP+W1E<W0@&UMM&ULR-#LQ2!M;,C0[,4@;6TML:6YE(#(T#0IL
 M:6YE(#(U#0H;6S(T.S%(&UM+&ULW;2A%3D0I(!M;;1M;,C0[,4@;6TL;6S\Q
 M;!L^<W1A<V@E(&9G#0T*=FD@+W1M<"]T97-T#0H;6S\Q:!L]&UL_,6@;/1M;
 M,3LR-'(;6VT;6S\W:!M;2!M;2B!F;V\-&UM";&EN92`Q#1M;0FQI;F4@,@T;
 M6T)L:6YE(#0-&UM";&EN92`U#1M;0FQI;F4@-@T;6T)L:6YE(#<-&UM";&EN
 M92`X#1M;0FQI;F4@.0T;6T)L:6YE(#$P#1M;0FQI;F4@,3$-&UM";&EN92`Q
 M,@T;6T)L:6YE(#$S#1M;0FQI;F4@,30-&UM";&EN92`Q-0T;6T)L:6YE(#$V
 M#1M;0FQI;F4@,3<-&UM";&EN92`Q.`T;6T)L:6YE(#$Y#1M;0FQI;F4@,3D-
 M&UM";&EN92`R,`T;6T)L:6YE(#(Q#1M;0FQI;F4@,C(-&UM"&ULW;55S86=E
 M.B!:6AM;2!M;0QM;;1M;,C-""!M;2QM;2"`;6T@;6TH@9F]O#1M;0FQI;F4@
 M,0T;6T)L:6YE(#(-&UM";&EN92`T#1M;0FQI;F4@-0T;6T)L:6YE(#8-&UM"
 M;&EN92`W#1M;0FQI;F4@.`T;6T)L:6YE(#D-&UM";&EN92`Q,`T;6T)L:6YE
 M(#$Q#1M;0FQI;F4@,3(-&UM";&EN92`Q,PT;6T)L:6YE(#$T#1M;0FQI;F4@
 M,34-&UM";&EN92`Q-@T;6T)L:6YE(#$W#1M;0FQI;F4@,3@-&UM";&EN92`Q
 M.0T;6T)L:6YE(#$Y#1M;0FQI;F4@,C`-&UM";&EN92`R,0T;6T)L:6YE(#(R
 M&UM((!M;2!M;2B!F;V\-&UM";&EN92`Q#1M;0FQI;F4@,@T;6T)L:6YE(#0-
 M&UM";&EN92`U#1M;0FQI;F4@-@T;6T)L:6YE(#<-&UM";&EN92`X#1M;0FQI
 M;F4@.0T;6T)L:6YE(#$P#1M;0FQI;F4@,3$-&UM";&EN92`Q,@T;6T)L:6YE
 M(#$S#1M;0FQI;F4@,30-&UM";&EN92`Q-0T;6T)L:6YE(#$V#1M;0FQI;F4@
 M,3<-&UM";&EN92`Q.`T;6T)L:6YE(#$Y#1M;0FQI;F4@,3D-&UM";&EN92`R
 M,`T;6T)L:6YE(#(Q#1M;0FQI;F4@,C(;6T@@&UM(&UM*(&9O;PT;6T)L:6YE
 M(#$-&UM";&EN92`R#1M;0FQI;F4@-`T;6T)L:6YE(#4-&UM";&EN92`V#1M;
 M0FQI;F4@-PT;6T)L:6YE(#@-&UM";&EN92`Y#1M;0FQI;F4@,3`-&UM";&EN
 M92`Q,0T;6T)L:6YE(#$R#1M;0FQI;F4@,3,-&UM";&EN92`Q-`T;6T)L:6YE
 M(#$U#1M;0FQI;F4@,38-&UM";&EN92`Q-PT;6T)L:6YE(#$X#1M;0FQI;F4@
 M,3D-&UM";&EN92`Q.0T;6T)L:6YE(#(P#1M;0FQI;F4@,C$-&UM";&EN92`R
 M,AM;2"`;6T@;6TH@9F]O#1M;0FQI;F4@,0T;6T)L:6YE(#(-&UM";&EN92`T
 M#1M;0FQI;F4@-0T;6T)L:6YE(#8-&UM";&EN92`W#1M;0FQI;F4@.`T;6T)L
 M:6YE(#D-&UM";&EN92`Q,`T;6T)L:6YE(#$Q#1M;0FQI;F4@,3(-&UM";&EN
 M92`Q,PT;6T)L:6YE(#$T#1M;0FQI;F4@,34-&UM";&EN92`Q-@T;6T)L:6YE
 M(#$W#1M;0FQI;F4@,3@-&UM";&EN92`Q.0T;6T)L:6YE(#$Y#1M;0FQI;F4@
 M,C`-&UM";&EN92`R,0T;6T)L:6YE(#(R&UM((!M;,C-"""]T;7`O=&5S=#H@
 M,C8@;&EN97,L(#$Y-B!C:&%R86-T97)S&UM((!M;/S%L&SX;6S(S0@@;1!M;
 M,C0[,4@-&UL_,6P;/G-T87-H)2!C870@+W1M<"]T97-T#0T*(&9O;PT*;&EN
 M92`Q#0IL:6YE(#(-"FQI;F4@,PT*;&EN92`T#0IL:6YE(#4-"FQI;F4@-@T*
 M;&EN92`W#0IL:6YE(#@-"FQI;F4@.0T*;&EN92`Q,`T*;&EN92`Q,0T*;&EN
 M92`Q,@T*;&EN92`Q,PT*;&EN92`Q-`T*;&EN92`Q-0T*;&EN92`Q-@T*;&EN
 M92`Q-PT*;&EN92`Q.`T*;&EN92`Q.0T*;&EN92`R,`T*;&EN92`R,0T*;&EN
 M92`R,@T*;&EN92`R,PT*;&EN92`R-`T*;&EN92`R-0T*<W1A<V@E(%Y$"`AE
 M>&ET#0H*4V-R:7!T(&1O;F4@;VX@5'5E($9E8B`Q.2`Q-SHR-3HU-R`R,#`R
 !"FET
 `
 end

From: Bill Fenner <fenner@research.att.com>
To: sheldonh@FreeBSD.org
Cc:  
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 19 Feb 2002 17:20:01 -0800 (PST)

 The following reply was made to PR bin/3170; it has been noted by GNATS.
 
 From: Bill Fenner <fenner@research.att.com>
 To: freebsd-gnats-submit@FreeBSD.org, fenner@research.att.com
 Cc:  
 Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
 Date: Tue, 19 Feb 2002 17:11:42 -0800
 
  Although vi no longer dumps core when this situation occurs, the message
  output is not correct, and the editing session behaves quite
  unpredictably.  When I do the experiment, vi now displays the following
  3 lines and hangs waiting for input:
  
  +=+=+=+=+=+=+=+
  Information on user id 639 not found.
   
  
  (yes, 3 lines -- the bottom line of the screen is blank).
  If I hit enter, it then says
  
  Press any key to continue:
  
  and the editing session proceeds with the screen in an inconsistent
  state, with the next input character causing multiple things to occur.
  
  I'm not convinced this is an improvement.  At least with the core dump,
  you're not going to do unexpected things to your file.  Please don't
  close this PR.

From: Bill Fenner <fenner@research.att.com>
To: sheldonh@FreeBSD.org
Cc:  
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 19 Feb 2002 18:00:05 -0800 (PST)

 The following reply was made to PR bin/3170; it has been noted by GNATS.
 
 From: Bill Fenner <fenner@research.att.com>
 To: freebsd-gnats-submit@freebsd.org
 Cc:  
 Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
 Date: Tue, 19 Feb 2002 17:50:59 -0800 (PST)
 
  more detail on the behavior on -current (FreeBSD stash.attlabs.att.com 5.0-CURRENT FreeBSD 5.0-CURRENT #70: Fri Feb 15 19:55:33 PST 2002     fenner@stash.attlabs.att.com:/usr/obj/usr/src/sys/STASHNOV6  i386):
  I created a file with "line 1" through "line 25".
  
  typed "O" at the top of file, screen looks like:
  
  vvvvv
  line 1
  line 2
  line 3
  line 4
  line 5
  line 6
  line 7
  line 8
  line 9
  line 10
  line 11
  line 12
  line 13
  line 14
  line 15
  line 16
  line 17
  line 18
  line 19
  line 20
  line 21
  +=+=+=+=+=+=+=+
  Information on user id 639 not found.
  
  ^^^^^
  
  Hit space, since it looks like it's waiting for a key.
  
  screen looks like:
  
  vvvvv
  line 1
  line 2
  line 3
  line 4
  line 5
  line 6
  line 7
  line 8
  line 9
  line 10
  line 11
  line 12
  line 13
  line 14
  line 15
  line 16
  line 17
  line 18
  line 19
  line 20
  +=+=+=+=+=+=+=+
  Information on user id 639 not found.
  
  Press any key to continue: 
  ^^^^^
  
  I press any key to continue, now the space looks like it was taken
  as a movement, since the cursor is on the "i" of "line 1".
  
  if I type "foo", the screen now looks like
  ("line 1" disappeared as soon as I typed the "f")
  
  vvvvv
   foo
  line 2
  line 3
  line 4
  line 5
  line 6
  line 7
  line 8
  line 9
  line 10
  line 11
  line 12
  line 13
  line 14
  line 15
  line 16
  line 17
  line 18
  line 19
  line 19
  line 20
  line 21
  line 22
  
  ^^^^
  
  and line 1 is missing from the screen.  Also note two copies of "line 19".
  
  Saving the file results in a file which has
  
  vvvvvv
  stash% cat /tmp/test
   foo
  line 1
  line 2
  line 3
  line 4
  line 5
  line 6
  line 7
  line 8
  line 9
  line 10
  line 11
  line 12
  line 13
  line 14
  line 15
  line 16
  line 17
  line 18
  line 19
  line 20
  line 21
  line 22
  line 23
  line 24
  line 25
  ^^^^^
  
  typescript of this session:
  
  begin 664 typescript
  M4V-R:7!T('-T87)T960@;VX@5'5E($9E8B`Q.2`Q-SHQ-#HS,R`R,#`R"G-T
  M87-H)2!V:2`O=&UP+W1E<W0-#0H;6S$[,C1R&UMM&UL_-V@;6S\Q:!L]&UM(
  M&UM*;&EN92`Q#1M;0FQI;F4@,@T;6T)L:6YE(#,-&UM";&EN92`T#1M;0FQI
  M;F4@-0T;6T)L:6YE(#8-&UM";&EN92`W#1M;0FQI;F4@.`T;6T)L:6YE(#D-
  M&UM";&EN92`Q,`T;6T)L:6YE(#$Q#1M;0FQI;F4@,3(-&UM";&EN92`Q,PT;
  M6T)L:6YE(#$T#1M;0FQI;F4@,34-&UM";&EN92`Q-@T;6T)L:6YE(#$W#1M;
  M0FQI;F4@,3@-&UM";&EN92`Q.0T;6T)L:6YE(#(P#1M;0FQI;F4@,C$-&UM"
  M;&EN92`R,@T;6T)L:6YE(#(S&UM(&ULR,T(O=&UP+W1E<W0Z('5N;6]D:69I
  M960Z(&QI;F4@,1M;2!M;,C-"&ULW;4EN9F]R;6%T:6]N(&]N('5S97(@:60@
  M-C,Y(&YO="!F;W5N9!M;2!M;;1M;,C%"&ULW;2L]*STK/2L]*STK/2L]*PT;
  M6T));F9O<FUA=&EO;B!O;B!U<V5R(&ED(#8S.2!N;W0@9F]U;F0N#1M;0DUO
  M9&EF:6-A=&EO;G,@;F]T(')E8V]V97)A8FQE(&EF('1H92!S97-S:6]N(&9A
  M:6QS&UM(&UMM&ULR,T(;6TL;6T@;6S(P0AM;31M;,T)0<F5S<R!A;GD@:V5Y
  M('1O(&-O;G1I;G5E.B`;6S$Y.S(R<AM;,3D[,4@;31M;,3LR-'(;6S$Y.S%(
  M;&EN92`Q.0T;6S-";&EN92`R,1M;2PT;6T)L:6YE(#(R#1M;0AM;2QM;2&P(
  M(&8;6TMO;P@;6T@;6TH@9F]O#1M;0FQI;F4@,@T;6T)L:6YE(#,-&UM";&EN
  M92`T#1M;0FQI;F4@-0T;6T)L:6YE(#8-&UM";&EN92`W#1M;0FQI;F4@.`T;
  M6T)L:6YE(#D-&UM";&EN92`Q,`T;6T)L:6YE(#$Q#1M;0FQI;F4@,3(-&UM"
  M;&EN92`Q,PT;6T)L:6YE(#$T#1M;0FQI;F4@,34-&UM";&EN92`Q-@T;6T)L
  M:6YE(#$W#1M;0FQI;F4@,3@-&UM";&EN92`Q.0T;6T)L:6YE(#$Y#1M;0FQI
  M;F4@,C`-&UM";&EN92`R,0T;6T)L:6YE(#(R&UM((&9O&UM(&UM*(&9O;PT;
  M6T)L:6YE(#(-&UM";&EN92`S#1M;0FQI;F4@-`T;6T)L:6YE(#4-&UM";&EN
  M92`V#1M;0FQI;F4@-PT;6T)L:6YE(#@-&UM";&EN92`Y#1M;0FQI;F4@,3`-
  M&UM";&EN92`Q,0T;6T)L:6YE(#$R#1M;0FQI;F4@,3,-&UM";&EN92`Q-`T;
  M6T)L:6YE(#$U#1M;0FQI;F4@,38-&UM";&EN92`Q-PT;6T)L:6YE(#$X#1M;
  M0FQI;F4@,3D-&UM";&EN92`Q.0T;6T)L:6YE(#(P#1M;0FQI;F4@,C$-&UM"
  M;&EN92`R,AM;2"!F;QM;2!M;2B!F;V\-&UM";&EN92`R#1M;0FQI;F4@,PT;
  M6T)L:6YE(#0-&UM";&EN92`U#1M;0FQI;F4@-@T;6T)L:6YE(#<-&UM";&EN
  M92`X#1M;0FQI;F4@.0T;6T)L:6YE(#$P#1M;0FQI;F4@,3$-&UM";&EN92`Q
  M,@T;6T)L:6YE(#$S#1M;0FQI;F4@,30-&UM";&EN92`Q-0T;6T)L:6YE(#$V
  M#1M;0FQI;F4@,3<-&UM";&EN92`Q.`T;6T)L:6YE(#$Y#1M;0FQI;F4@,3D-
  M&UM";&EN92`R,`T;6T)L:6YE(#(Q#1M;0FQI;F4@,C(;6T@@9F\;6T@;6TH@
  M9F]O#1M;0FQI;F4@,@T;6T)L:6YE(#,-&UM";&EN92`T#1M;0FQI;F4@-0T;
  M6T)L:6YE(#8-&UM";&EN92`W#1M;0FQI;F4@.`T;6T)L:6YE(#D-&UM";&EN
  M92`Q,`T;6T)L:6YE(#$Q#1M;0FQI;F4@,3(-&UM";&EN92`Q,PT;6T)L:6YE
  M(#$T#1M;0FQI;F4@,34-&UM";&EN92`Q-@T;6T)L:6YE(#$W#1M;0FQI;F4@
  M,3@-&UM";&EN92`Q.0T;6T)L:6YE(#$Y#1M;0FQI;F4@,C`-&UM";&EN92`R
  M,0T;6T)L:6YE(#(R&UM((&9O&UM(&UM*(&9O;PT;6T)L:6YE(#(-&UM";&EN
  M92`S#1M;0FQI;F4@-`T;6T)L:6YE(#4-&UM";&EN92`V#1M;0FQI;F4@-PT;
  M6T)L:6YE(#@-&UM";&EN92`Y#1M;0FQI;F4@,3`-&UM";&EN92`Q,0T;6T)L
  M:6YE(#$R#1M;0FQI;F4@,3,-&UM";&EN92`Q-`T;6T)L:6YE(#$U#1M;0FQI
  M;F4@,38-&UM";&EN92`Q-PT;6T)L:6YE(#$X#1M;0FQI;F4@,3D-&UM";&EN
  M92`Q.0T;6T)L:6YE(#(P#1M;0FQI;F4@,C$-&UM";&EN92`R,AM;2"!F;P<'
  M&UM"&UM"&UM!&UM!!P<;6T(;6T(;6T(;6T(;6T(;6T(;6T(;6T(;6T(;6T(;
  M6T(;6T(;6T(;6T(;6T(;6T(;6T(;6T(;6T@;6S--&ULR,$)L:6YE(#(S#1M;
  M0FQI;F4@,C0-&UM";&EN92`R-0T'&UM(&UM*;&EN92`T#1M;0FQI;F4@-0T;
  M6T)L:6YE(#8-&UM";&EN92`W#1M;0FQI;F4@.`T;6T)L:6YE(#D-&UM";&EN
  M92`Q,`T;6T)L:6YE(#$Q#1M;0FQI;F4@,3(-&UM";&EN92`Q,PT;6T)L:6YE
  M(#$T#1M;0FQI;F4@,34-&UM";&EN92`Q-@T;6T)L:6YE(#$W#1M;0FQI;F4@
  M,3@-&UM";&EN92`Q.0T;6T)L:6YE(#$Y#1M;0FQI;F4@,C`-&UM";&EN92`R
  M,0T;6T)L:6YE(#(R#1M;0FQI;F4@,C,-&UM";&EN92`R-`T;6T)L:6YE(#(U
  M#1M;2!M;2FQI;F4@-`T;6T)L:6YE(#4-&UM";&EN92`V#1M;0FQI;F4@-PT;
  M6T)L:6YE(#@-&UM";&EN92`Y#1M;0FQI;F4@,3`-&UM";&EN92`Q,0T;6T)L
  M:6YE(#$R#1M;0FQI;F4@,3,-&UM";&EN92`Q-`T;6T)L:6YE(#$U#1M;0FQI
  M;F4@,38-&UM";&EN92`Q-PT;6T)L:6YE(#$X#1M;0FQI;F4@,3D-&UM";&EN
  M92`Q.0T;6T)L:6YE(#(P#1M;0FQI;F4@,C$-&UM";&EN92`R,@T;6T)L:6YE
  M(#(S#1M;0FQI;F4@,C0-&UM";&EN92`R-0T;6S$[,C-R&ULQ.S%(&ULS3!M;
  M,3LR-'(;6S$[,DAF;V\-&UM";&EN92`Q#1M;0FQI;F4@,@T;6S$Q0AM;2!M;
  M0AM;02`'&ULR,T((+W1M<"]T97-T.B!M;V1I9FEE9#H@;&EN92`Q(&]F(#(V
  M(%LS)5T;6T@@"!M;,TT;6S(P0FQI;F4@,C,;6TL-&UM";&EN92`R-`T;6T)L
  M:6YE(#(U&ULQ.3LQ2!M;-$(;6S$[,C-R&ULQ.S%(&ULS3!M;,3LR-'(;6S$[
  M,DAF;V\-&UM";&EN92`Q#1M;0FQI;F4@,@T;6S$Q0AM;2!M;0AM;02`;6S(S
  M0@@;6S=M57-A9V4Z(%I:&UM(&UM#&UMM!QM;,C-""!M;/S%L&SX;6S(T.S%(
  M#1M;/S%L&SX-"E-U<W!E;F1E9`T*<W1A<V@E(&QE<W,@+W1M<"]T97-T(`T-
  M"AM;/S%H&ST;6S(T.S%(&UM+;&EN92`Q#0IL:6YE(#(-"FQI;F4@,PT*;&EN
  M92`T#0IL:6YE(#4-"FQI;F4@-@T*;&EN92`W#0IL:6YE(#@-"FQI;F4@.0T*
  M;&EN92`Q,`T*;&EN92`Q,0T*;&EN92`Q,@T*;&EN92`Q,PT*;&EN92`Q-`T*
  M;&EN92`Q-0T*;&EN92`Q-@T*;&EN92`Q-PT*;&EN92`Q.`T*;&EN92`Q.0T*
  M;&EN92`R,`T*;&EN92`R,0T*;&EN92`R,@T*;&EN92`R,PT*&ULR-#LQ2!M;
  M2QM;-VTO=&UP+W1E<W0@&UMM&ULR-#LQ2!M;,C0[,4@;6TML:6YE(#(T#0IL
  M:6YE(#(U#0H;6S(T.S%(&UM+&ULW;2A%3D0I(!M;;1M;,C0[,4@;6TL;6S\Q
  M;!L^<W1A<V@E(&9G#0T*=FD@+W1M<"]T97-T#0H;6S\Q:!L]&UL_,6@;/1M;
  M,3LR-'(;6VT;6S\W:!M;2!M;2B!F;V\-&UM";&EN92`Q#1M;0FQI;F4@,@T;
  M6T)L:6YE(#0-&UM";&EN92`U#1M;0FQI;F4@-@T;6T)L:6YE(#<-&UM";&EN
  M92`X#1M;0FQI;F4@.0T;6T)L:6YE(#$P#1M;0FQI;F4@,3$-&UM";&EN92`Q
  M,@T;6T)L:6YE(#$S#1M;0FQI;F4@,30-&UM";&EN92`Q-0T;6T)L:6YE(#$V
  M#1M;0FQI;F4@,3<-&UM";&EN92`Q.`T;6T)L:6YE(#$Y#1M;0FQI;F4@,3D-
  M&UM";&EN92`R,`T;6T)L:6YE(#(Q#1M;0FQI;F4@,C(-&UM"&ULW;55S86=E
  M.B!:6AM;2!M;0QM;;1M;,C-""!M;2QM;2"`;6T@;6TH@9F]O#1M;0FQI;F4@
  M,0T;6T)L:6YE(#(-&UM";&EN92`T#1M;0FQI;F4@-0T;6T)L:6YE(#8-&UM"
  M;&EN92`W#1M;0FQI;F4@.`T;6T)L:6YE(#D-&UM";&EN92`Q,`T;6T)L:6YE
  M(#$Q#1M;0FQI;F4@,3(-&UM";&EN92`Q,PT;6T)L:6YE(#$T#1M;0FQI;F4@
  M,34-&UM";&EN92`Q-@T;6T)L:6YE(#$W#1M;0FQI;F4@,3@-&UM";&EN92`Q
  M.0T;6T)L:6YE(#$Y#1M;0FQI;F4@,C`-&UM";&EN92`R,0T;6T)L:6YE(#(R
  M&UM((!M;2!M;2B!F;V\-&UM";&EN92`Q#1M;0FQI;F4@,@T;6T)L:6YE(#0-
  M&UM";&EN92`U#1M;0FQI;F4@-@T;6T)L:6YE(#<-&UM";&EN92`X#1M;0FQI
  M;F4@.0T;6T)L:6YE(#$P#1M;0FQI;F4@,3$-&UM";&EN92`Q,@T;6T)L:6YE
  M(#$S#1M;0FQI;F4@,30-&UM";&EN92`Q-0T;6T)L:6YE(#$V#1M;0FQI;F4@
  M,3<-&UM";&EN92`Q.`T;6T)L:6YE(#$Y#1M;0FQI;F4@,3D-&UM";&EN92`R
  M,`T;6T)L:6YE(#(Q#1M;0FQI;F4@,C(;6T@@&UM(&UM*(&9O;PT;6T)L:6YE
  M(#$-&UM";&EN92`R#1M;0FQI;F4@-`T;6T)L:6YE(#4-&UM";&EN92`V#1M;
  M0FQI;F4@-PT;6T)L:6YE(#@-&UM";&EN92`Y#1M;0FQI;F4@,3`-&UM";&EN
  M92`Q,0T;6T)L:6YE(#$R#1M;0FQI;F4@,3,-&UM";&EN92`Q-`T;6T)L:6YE
  M(#$U#1M;0FQI;F4@,38-&UM";&EN92`Q-PT;6T)L:6YE(#$X#1M;0FQI;F4@
  M,3D-&UM";&EN92`Q.0T;6T)L:6YE(#(P#1M;0FQI;F4@,C$-&UM";&EN92`R
  M,AM;2"`;6T@;6TH@9F]O#1M;0FQI;F4@,0T;6T)L:6YE(#(-&UM";&EN92`T
  M#1M;0FQI;F4@-0T;6T)L:6YE(#8-&UM";&EN92`W#1M;0FQI;F4@.`T;6T)L
  M:6YE(#D-&UM";&EN92`Q,`T;6T)L:6YE(#$Q#1M;0FQI;F4@,3(-&UM";&EN
  M92`Q,PT;6T)L:6YE(#$T#1M;0FQI;F4@,34-&UM";&EN92`Q-@T;6T)L:6YE
  M(#$W#1M;0FQI;F4@,3@-&UM";&EN92`Q.0T;6T)L:6YE(#$Y#1M;0FQI;F4@
  M,C`-&UM";&EN92`R,0T;6T)L:6YE(#(R&UM((!M;,C-"""]T;7`O=&5S=#H@
  M,C8@;&EN97,L(#$Y-B!C:&%R86-T97)S&UM((!M;/S%L&SX;6S(S0@@;1!M;
  M,C0[,4@-&UL_,6P;/G-T87-H)2!C870@+W1M<"]T97-T#0T*(&9O;PT*;&EN
  M92`Q#0IL:6YE(#(-"FQI;F4@,PT*;&EN92`T#0IL:6YE(#4-"FQI;F4@-@T*
  M;&EN92`W#0IL:6YE(#@-"FQI;F4@.0T*;&EN92`Q,`T*;&EN92`Q,0T*;&EN
  M92`Q,@T*;&EN92`Q,PT*;&EN92`Q-`T*;&EN92`Q-0T*;&EN92`Q-@T*;&EN
  M92`Q-PT*;&EN92`Q.`T*;&EN92`Q.0T*;&EN92`R,`T*;&EN92`R,0T*;&EN
  M92`R,@T*;&EN92`R,PT*;&EN92`R-`T*;&EN92`R-0T*<W1A<V@E(%Y$"`AE
  M>&ET#0H*4V-R:7!T(&1O;F4@;VX@5'5E($9E8B`Q.2`Q-SHR-3HU-R`R,#`R
  !"FET
  `
  end
Responsible-Changed-From-To: sheldonh->freebsd-bugs 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Tue Feb 17 03:19:07 PST 2004 
Responsible-Changed-Why:  
Release. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=3170 
Responsible-Changed-From-To: freebsd-bugs->linimon 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sat Jan 26 00:45:12 UTC 2008 
Responsible-Changed-Why:  
Bill, does this antique PR still apply, or has this been fixed in the 
last few years? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=3170 

From: Marc Olzheim <marcolz@stack.nl>
To: bug-followup@FreeBSD.org, Bill Fenner <fenner@research.att.com>
Cc: Marc Olzheim <marcolz@stack.nl>
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 20 May 2008 12:47:46 +0200

 This seems to have been fixed a long time ago; I can't even reproduce it
 on a 3.3-RELEASE system (and not on 7-STABLE either).
 
 Marc
State-Changed-From-To: analyzed->closed 
State-Changed-By: linimon 
State-Changed-When: Tue May 20 14:34:35 UTC 2008 
State-Changed-Why:  
A more recent reply suggests that this PR is obsolete. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=3170 

From: "Bill Fenner" <fenner@FreeBSD.org>
To: "Bill Fenner" <fenner@freebsd.org>
Cc: "Marc Olzheim" <marcolz@stack.nl>, bug-followup@freebsd.org
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 20 May 2008 07:33:45 -0700

 It behaves the same in 6.2 as I described in 5.0 -- if I open a line
 with "O", it puts the following at the bottom of the screen:
 
 +=+=+=+=+=+=+=+
 Information on user id 1001 not found.
 
 and then silently waits for input; if I hit space, I get:
 
 Press any key to continue:
 
 When I press a key to continue, the cursor is in the middle of an
 existing line, not in an empty line as the "O" command requested.  It
 looks like the space that I hit to get the "press any key to continue"
 was also taken as input, since if I ^L after typing "hello", the
 buffer contains
 
 line 44
 line 45
  hello
 line 46
 line 47
 
 and I did not enter a space other than in response to the dialogs.

From: Bill Fenner <fenner@fenron.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 20 May 2008 07:41:14 -0700

 It behaves the same in 6.2 as I described in 5.0 -- if I open a line
 with "O", it puts the following at the bottom of the screen:
 
 +=+=+=+=+=+=+=+
 Information on user id 1001 not found.
 
 and then silently waits for input; if I hit space, I get:
 
 Press any key to continue:
 
 When I press a key to continue, the cursor is in the middle of an
 existing line, not in an empty line as the "O" command requested.  It
 looks like the space that I hit to get the "press any key to continue"
 was also taken as input, since if I ^L after typing "hello", the
 buffer contains
 
 line 44
 line 45
   hello
 line 46
 line 47
 
 and I did not enter a space other than in response to the dialogs.
 
 However, I don't see the point of keeping the PR around -- nobody is  
 going to fix it.
 

From: "Bill Fenner" <fenner@FreeBSD.org>
To: "Marc Olzheim" <marcolz@stack.nl>
Cc: bug-followup@freebsd.org
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 20 May 2008 07:18:19 -0700

 Then you're not following the right steps, since if you follow the
 audit trail it's reproducible in 4.0 and a variation is present in
 5.0.
 
 I haven't been able to reproduce it in 6.2 but I only tried once since
 I forgot to leave myself a way to recover from having deleted my
 account.  Oops ;-)
 
   Bill

From: Marc Olzheim <marcolz@stack.nl>
To: Bill Fenner <fenner@FreeBSD.org>
Cc: Marc Olzheim <marcolz@stack.nl>, bug-followup@freebsd.org
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 20 May 2008 17:47:42 +0200

 On Tue, May 20, 2008 at 07:18:19AM -0700, Bill Fenner wrote:
 > Then you're not following the right steps, since if you follow the
 > audit trail it's reproducible in 4.0 and a variation is present in
 > 5.0.
 
 Well, I run the shell of the testuser with an empty environment, only
 copying PATH, TERM and HOME and no .exrc present in the homedir, with
 env - PATH=$PATH TERM=$TERM HOME=$HOME /bin/sh
 
 For me, on FreeBSD 3.3-RELEASE and 4.11-STABLE, /usr/bin/vi doesn't
 crash, nor prints the message, nor garbles the screen.  When I kill it
 with sigterm, it leaves an empty file in /var/tmp/vi.recover/
 
 Marc

From: Bill Fenner <fenner@fenron.com>
To: Marc Olzheim <marcolz@stack.nl>
Cc: bug-followup@freebsd.org
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 20 May 2008 10:44:27 -0700

 On May 20, 2008, at 8:47 AM, Marc Olzheim wrote:
 > Well, I run the shell of the testuser with an empty environment, only
 > copying PATH, TERM and HOME and no .exrc present in the homedir, with
 > env - PATH=$PATH TERM=$TERM HOME=$HOME /bin/sh
 >
 > For me, on FreeBSD 3.3-RELEASE and 4.11-STABLE, /usr/bin/vi doesn't
 > crash, nor prints the message, nor garbles the screen.  When I kill it
 > with sigterm, it leaves an empty file in /var/tmp/vi.recover/
 
 It's easy to fail to reproduce it.  Many people have successfully not  
 reproduced it.  Reproducing it requires following the precise steps I  
 describe, and many people trying to reproduce it skip some steps or  
 don't do precisely the same thing, resulting in a non-reproduction.  
 However, since I have reproduced it on 4.0, 5.0, and can still  
 reproduce it, using the steps I supplied, on 6.2, can we agree that it  
 still exists in 6.2?
 
    Bill
 
State-Changed-From-To: closed->suspended 
State-Changed-By: linimon 
State-Changed-When: Tue May 20 18:11:03 UTC 2008 
State-Changed-Why:  
fenner says this one still exists.  So much for the award for closing 
the oldest PR this week ... 


Responsible-Changed-From-To: linimon->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Tue May 20 18:11:03 UTC 2008 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=3170 

From: Marc Olzheim <marcolz@stack.nl>
To: Bill Fenner <fenner@fenron.com>
Cc: Marc Olzheim <marcolz@stack.nl>, bug-followup@freebsd.org
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 27 May 2008 10:27:11 +0200

 On Tue, May 20, 2008 at 10:44:27AM -0700, Bill Fenner wrote:
 > It's easy to fail to reproduce it.  Many people have successfully not  
 > reproduced it.  Reproducing it requires following the precise steps I  
 > describe, and many people trying to reproduce it skip some steps or  
 > don't do precisely the same thing, resulting in a non-reproduction.  
 > However, since I have reproduced it on 4.0, 5.0, and can still  
 > reproduce it, using the steps I supplied, on 6.2, can we agree that it  
 > still exists in 6.2?
 
 Well, the missing information seems to have to do with the terminal. I
 managed to reproduce it now. The step that's missing in the description,
 is that this only seems to happen on a virtual terminal on console.
 
 At least, I still haven't reproduced it on any other terminal (emulator).
 
 Apologies, Mark, for missing the award. ;-)
 
 Marc

From: "Bill Fenner" <fenner@fenron.com>
To: "Marc Olzheim" <marcolz@stack.nl>
Cc: bug-followup@freebsd.org
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 27 May 2008 05:29:16 -0700

 On Tue, May 27, 2008 at 1:27 AM, Marc Olzheim <marcolz@stack.nl> wrote:
 > Well, the missing information seems to have to do with the terminal. I
 > managed to reproduce it now. The step that's missing in the description,
 > is that this only seems to happen on a virtual terminal on console.
 
 I first experienced it with an xterm running on a local X server;
 since it was so long ago I assume my terminal type was set to 'xterm'.
  Last week I reproduced it by ssh'ing in from a MacOS X 'Terminal'
 with my term type set to 'xterm-color'.  I never had a terminal type
 on which I couldn't reproduce it, so didn't think to include that
 information in the bug; sorry for the oversight.
 
   Bill

From: Marc Olzheim <marcolz@stack.nl>
To: Bill Fenner <fenner@fenron.com>
Cc: Marc Olzheim <marcolz@stack.nl>, bug-followup@freebsd.org
Subject: Re: bin/3170: vi freaks and dump core if user doesn't exist
Date: Tue, 27 May 2008 16:32:59 +0200

 On Tue, May 27, 2008 at 05:29:16AM -0700, Bill Fenner wrote:
 > > Well, the missing information seems to have to do with the terminal. I
 > > managed to reproduce it now. The step that's missing in the description,
 > > is that this only seems to happen on a virtual terminal on console.
 > 
 > I first experienced it with an xterm running on a local X server;
 > since it was so long ago I assume my terminal type was set to 'xterm'.
 >  Last week I reproduced it by ssh'ing in from a MacOS X 'Terminal'
 > with my term type set to 'xterm-color'.  I never had a terminal type
 > on which I couldn't reproduce it, so didn't think to include that
 > information in the bug; sorry for the oversight.
 
 It's not triggered in a gnome-terminal, with TERM=xterm, but it is in
 a 'real' xterm and still reproduceable on FreeBSD 7.0-STABLE. :-/
 
 Marc

From: Ed Maste <emaste@freebsd.org>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/3170: vi(1): vi freaks and dump core if user doesn't exist
Date: Sun, 17 Jan 2010 09:03:54 -0500

 I happened to try this on a few-days-old 9.0-CURRENT and wasn't able
 to reproduce the problem (or even the warning message) when running in 
 gnome-terminal.  When connected by ssh I did get the warning message,
 but no segfault.
State-Changed-From-To: suspended->closed 
State-Changed-By: gnn 
State-Changed-When: Sat Jul 28 19:51:05 UTC 2012 
State-Changed-Why:  
Proof that if you wait long enough all bugs get fixed. 

I have verified that this is no longer a bug on 10 (HEAD). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=3170 
>Unformatted:
