Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!rpi!pawl!shadow
From: shadow@pawl.rpi.edu (Deven T. Corzine)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Catching free memory violations
Message-ID: <SHADOW.89Jul30162610@pawl.rpi.edu>
Date: 30 Jul 89 20:26:10 GMT
References: <7408@ecsvax.UUCP> <694@jc3b21.UUCP>
	<SHADOW.89Jul29071247@pawl.rpi.edu> <3985@cps3xx.UUCP>
Sender: usenet@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY
Lines: 63
In-reply-to: usenet@cps3xx.UUCP's message of 30 Jul 89 17:48:54 GMT


On 30 Jul 89 17:48:54 GMT,
usenet@cps3xx.UUCP (Usenet file owner) said:

porkka> In article <SHADOW.89Jul29071247@pawl.rpi.edu>
porkka> shadow@pawl.rpi.edu (Deven T. Corzine) writes:

Deven> FreeMem() function to zero memory *as it is freed*.  Then either a
Deven> SetFunction()ed AllocMem() function or some separate task/function

porkka>  There is a sticky problem with this idea,

porkka> 	function() {
porkka> 		x=AllocMem()
porkka> 		playwithit(x);
porkka> 		Forbid();
porkka> 		FreeMem(x,len);
porkka> 		playsomemore(x);
porkka> 		Permit();
porkka> 	}

porkka> No if you go zeroing things out at the FreeMem call, you can
porkka> potentially screw somebody up.

True.  Of course, the first 8 bytes of the freed chunk is going to be
lost to the next-node pointer anyhow.  This difficulty could be
avoided by adding some state information.  When FreeMem() is called,
if the task is in a forbidden (or disabled) state, free the memory,
but do not zero.  Either simply set a "zero free memory" bit or add an
entry to a list of freed, yet-to-be-zeroed blocks of memory.  (or have
a separate lists for free memory -- one zeroed, one not)

Using a single bit somewhere is simplest, but it means the entire free
list must be scanned and rezeroed, a likely-to-be-lengthy procedure,
and has the disadvantage of possibly missing any "unauthorized"
mucking about in free memory.

Using a list of to-be-zeroed free blocks solves that, but has the
problem of requiring a memory allocation to free memory, unless this
bit of state information could possibly be encoded (safely and
legally) in the existing data structures.  Perhaps in a ln_Priority
field?  Hmm.

This whole thing brings another point to mind -- writing ReallocMem()
to do FreeMem, AllocMem, CopyMem, and AllocAbs on failure would not
work, because of the node pointer placed in the first 8 bytes upon
that first FreeMem...  [subtle flaw, that.]

porkka> When a task is ending, does the Tasks memory get freed before
porkka> it actually returns?

Any memory in the task's tc_MemEntry field will be safely freed
(regardless of any such zeroing) by RemTask().  (If a compiler's
exit() code frees the memory it is running in before calling RemTask
(or returning, normally to the system default finalizer code, which is
a RemTask(0L)) then there could indeed be problems.

Deven
--
Deven T. Corzine        Internet:  deven@rpi.edu, shadow@pawl.rpi.edu
Snail:  2214 12th Street, Troy, NY 12180       Phone:  (518) 271-0750
Bitnet:  deven@rpitsmts, userfxb6@rpitsmts     UUCP:  uunet!rpi!deven
Simple things should be simple and complex things should be possible.