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)