Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!nic.MR.NET!thor.acc.stolaf.edu!mike
From: mike@thor.acc.stolaf.edu (Mike Haertel)
Newsgroups: comp.unix.wizards
Subject: Re: Ever seen nondeterministic a.out execution from some filesystems?
Message-ID: <7221@thor.acc.stolaf.edu>
Date: 8 Oct 89 19:32:42 GMT
References: <11827@watcgl.waterloo.edu>
Reply-To: mike@thor.stolaf.edu ()
Distribution: comp
Organization: St. Olaf College, Northfield, MN
Lines: 22

In article <11827@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu writes:
>File system /tmp on our 4.3BSD vax8600's has a block size equal to its
>frag size equal to 8192.  When I compile and run different programs in
>this file system, sometimes they mysteriously die of Illegal instruction
>faults.  If I compile them ten times in a row, half the time the
>resulting a.out won't run.  Copying the a.out to another file in /tmp
>often fixes the problem.  Copying the file to another file system and
>running it from there always fixes the problem.  Only on /tmp do I
>have this problem.  If I run a faulting a.out under adb, it will fault
>and when I examine instructions near where it faults I see zeroes!

I've never seen that happen on a 4.3BSD vax, but something like it
happens on my 3b1.  Often when an executable has just been built,
immediately executing it will get a trap.  Waiting a few seconds
or running sync seems to cure the problem.  My guess would be that
VM paging isn't cooperating with the Unix block cache, in the case
of the 3b1.  I *really doubt* Berkeley would have that problem, but
it's something you can look for.
-- 
Mike Haertel <mike@stolaf.edu>
``There's nothing remarkable about it.  All one has to do is hit the right
  keys at the right time and the instrument plays itself.'' -- J. S. Bach