Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!pawl!shadow From: shadow@pawl.rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Catching free memory violations Message-ID: Date: 30 Jul 89 20:49:11 GMT References: <7408@ecsvax.UUCP> <694@jc3b21.UUCP> <15515@watdragon.waterloo.edu> Sender: usenet@rpi.edu Distribution: na Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 28 In-reply-to: sjorr@rose.waterloo.edu's message of 30 Jul 89 14:18:04 GMT On 30 Jul 89 14:18:04 GMT, sjorr@rose.waterloo.edu (Stephen Orr) said: Deven> The idea was to SetFunction() the FreeMem() function to zero Deven> memory *as it is freed*. Then either a SetFunction()ed Deven> AllocMem() function or some separate task/function could check Deven> the free list to make sure it is zeroed. If not, it is a sign Deven> of corruption. Stephen> One thing to watch for, zeroing the memory chunk may Stephen> not be enough, when the OS coallesces free chunks it probably Stephen> leaves the old forward pointer alone, and this could appear Stephen> as 'corrupted memory' unless the coallesce is done one the Stephen> fly just 'expanding' an existing free memory chunk, I'm not Stephen> sure, but this is to be considered. Oh! Sharp thinking, there. Yes, I had neglected to consider to that extent. I believe the coalescing is done by the FreeMem call. Certainly it would need to be zeroed when combining adjacent free memory blocks. 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.