Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Oct 1996 21:38:53 -0500 (EST)
From:      "John S. Dyson" <toor@dyson.iquest.net>
To:        msmith@atrad.adelaide.edu.au (Michael Smith)
Cc:        current@FreeBSD.org
Subject:   Re: 'dead' binary stays 'dead'?
Message-ID:  <199610100238.VAA09727@dyson.iquest.net>
In-Reply-To: <199610100143.LAA16437@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 10, 96 11:13:30 am

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> Obviously, machines with serious memory errors deserve to loose
> infinitely, but this box doesn't fall into that category.  It's
> survived numerous 'make world' cycles faultlessly, and stands up all
> day to the excessive pounding that the physics geeks here subject it
> to.
> 
> Comments? Refutations? Merciless laughter?
> 
You are describing a problem that I know *can* happen, but I don't know
why.  In essence, once you have a copy of a programs .text, .data in
memory, it will continue to be cached until the memory is reclaimed.
If any part of that image gets modified, then it will stay modified.
If you remove the file that has it's in-memory image broken, that
brokenness will go away.  However, if you try to copy the
file like:  cp ls ls.new, it is likely that ls.new will also be broken
because the same image that is executed is also in the buffer cache
(the cache and the image are pretty much one in the same.)  The
best way to make the problem go-away is to fill memory and cause the
broken binary to disappear.  Now, the complicated part is why it happened.

I just don't know why...

Are you using NFS?  Are you using the most recent -current (snap)?...
You know the typical questions :-).

John



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610100238.VAA09727>