From owner-freebsd-current Wed Oct 9 19:57:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA04156 for current-outgoing; Wed, 9 Oct 1996 19:57:24 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA04146; Wed, 9 Oct 1996 19:57:16 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id MAA16615; Thu, 10 Oct 1996 12:27:05 +0930 From: Michael Smith Message-Id: <199610100257.MAA16615@genesis.atrad.adelaide.edu.au> Subject: Re: 'dead' binary stays 'dead'? To: dyson@FreeBSD.org Date: Thu, 10 Oct 1996 12:27:05 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, current@FreeBSD.org In-Reply-To: <199610100238.VAA09727@dyson.iquest.net> from "John S. Dyson" at Oct 9, 96 09:38:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk John S. Dyson stands accused of saying: > > 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. ... but if these pages are the text and data, they're read-only, correct? ie. the only modification possible is via hardware error? > 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. The relevant part of the 'going away' incident looked like this : $ ls $ cp -r /usr/src/bin/ls . $ cd ls $ CFLAGS=-g; make $ gdb ls ../ls.core $ ./ls $ ls So I guess it's possible that the memory was reclaimed while I was rebuilding a new 'ls'. > Are you using NFS? Are you using the most recent -current (snap)?... > You know the typical questions :-). Sorry 8) NFS client only (but not on any of the filesystems being used), supped at about the same time as the latest SNAP. > John -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[