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>