Date: Wed, 9 Oct 1996 22:54:13 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: dyson@FreeBSD.org, msmith@atrad.adelaide.edu.au, current@FreeBSD.org Subject: Re: 'dead' binary stays 'dead'? Message-ID: <199610100354.WAA11855@dyson.iquest.net> In-Reply-To: <199610100257.MAA16615@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 10, 96 12:27:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? > Or software bug :-). (Memory stomp could cause it, or an incorrect mapping update in the VM code.) > > The relevant part of the 'going away' incident looked like this : > > $ ls > <drat, another core> > $ cp -r /usr/src/bin/ls . > $ cd ls > $ CFLAGS=-g; make > $ gdb ls ../ls.core > <traceback looks like total garbage> > $ ./ls > <works> > $ ls > <works> > > So I guess it's possible that the memory was reclaimed while I was rebuilding > a new 'ls'. > Probably. > > > 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. > We all need to keep an eye on the problem... This is the first time that I have heard of it -- but doesn't mean that it isn't there :-)... John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610100354.WAA11855>