Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site utah-gr.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!philabs!cmcl2!seismo!utah-cs!utah-gr!thomas From: thomas@utah-gr.UUCP (Spencer W. Thomas) Newsgroups: net.unix-wizards Subject: Re: vi core dumping on Sun 2 (fixed, but would like explanations) Message-ID: <1490@utah-gr.UUCP> Date: Thu, 27-Jun-85 13:06:44 EDT Article-I.D.: utah-gr.1490 Posted: Thu Jun 27 13:06:44 1985 Date-Received: Sun, 30-Jun-85 02:51:48 EDT References: <168@ittral.UUCP> <494@umcp-cs.UUCP> Reply-To: thomas@utah-gr.UUCP (Spencer W. Thomas) Organization: Univ of Utah CS Dept Lines: 18 I would bet on a bad spot in the swap area (or memory). As Chris points out, the sticky bit means "keep a copy of this program in swap space, even if nobody is running it". If the "running" copy of the program got corrupted, and then swapped out, you would keep on using the corrupted copy. A process is loaded into the swap area by first reading it into memory, then writing it out to swap, so if you had a bad memory location, it would be possible to corrupt the swap copy. Things you could try if it happens again: 1. Turn off the sticky bit and run vi a couple of times. I think the system will throw away the copy in the swap area, so you should be getting a clean copy. 2. Write a program that uses ptrace() to compare a "running" copy of vi to the binary (the running copy should get the bad swap version). -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)