Xref: utzoo comp.sys.mips:632 comp.sys.dec:3020 comp.unix.ultrix:3275
Path: utzoo!attcan!uunet!mcsun!ukc!icdoc!syma!aarons
From: aarons@syma.sussex.ac.uk (Aaron Sloman)
Newsgroups: comp.sys.mips,comp.sys.dec,comp.unix.ultrix
Subject: Re: Problems with Ultrix on DECStation (corrupted text segment)
Summary: it really does corrupt the text segment
Keywords: corrupted text segment on ultrix
Message-ID: <2479@syma.sussex.ac.uk>
Date: 13 Apr 90 00:31:03 GMT
References: <2476@syma.sussex.ac.uk> <5093@crltrx.crl.dec.com>
Organization: School of Cognitive & Computing Sciences, Sussex Univ. UK
Lines: 39

Previously I reported that in certain situations Ultrix allows the
text segment to be corrupted on a DECstation

jg@max.crl.dec.com (Jim Gettys) wrote in response:

> Date: 12 Apr 90 17:22:14 GMT
> Reply-To: jg@max.crl.dec.com (Jim Gettys)
> Organization: DEC Cambridge Research Lab

> Are you sure that this is what is going on?
>
> Remember the machine has seperate I and D caches.
>
> If you are doing run-time loading of code into your address
> space that you will be executing, you must flush the
> I-cache.  Failure to do so will cause random behavior as
> you are reporting. (i.e. executing whatever code happened to
> be left around in the Icache in those locations).
>
> I've seen N lisp/scheme implementors trip over this one, most
> recently within the last week....  So this sounds dreadfully
> familiar...
> 				- Jim

We did at first have trouble with the data cache, e.g. because a
user procedure that was being executed could be relocated as a
result of garbage collection that it triggered. However, this
problem was overcome by flushing the cache after each garbage
collection (although it took some effort to discover the correct
system call: the manual was wrong)!

This, however, is not the source of our current problem. We can
explicitly give a command to corrupt the text segment, then prove
that it has been corrupted by using "cmp" to compare it with a saved
copy. Ultrix should prevent the corruption and force an error.

I am surprised that nobody else has met this problem.

Aaron Sloman