Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mtune!codas!peora!ucf-cs!usfvax2!chips
From: chips@usfvax2.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Fragmentation on DOS - HELP !
Message-ID: <764@usfvax2.UUCP>
Date: Wed, 20-May-87 11:31:03 EDT
Article-I.D.: usfvax2.764
Posted: Wed May 20 11:31:03 1987
Date-Received: Fri, 22-May-87 01:19:02 EDT
References: <287@pyuxv.UUCP>
Organization: AT Engineering, Tampa, FL
Lines: 40
Summary: DOS won't free() far memory segments for you

In article <287@pyuxv.UUCP>, cim2@pyuxv.UUCP (Robert L. Fair) writes:
> Does anyone out there know how DOS handles massive amounts of dynamic
> allocation and freeing, in particular memory fragmentation. 
> 
> In particular some applications which do this run when the machine is
> first turned on, but fail later when the machine has been used for 
> a while.
> 	1. Microsoft C-compiler 4.0 when compiling a VERY large program
> 	2. Our own product, FORESEE*, when doing large amounts of virtual 
> 	aggregation (munching around 10 MB of doubles using a virtual
> 	array via dynamic disk swapping) [FORESEE is written in MS-C.]
> 
> 	Each time 2. is run it gets malloc failures earlier and earlier [...]
> 	Systems: IBM PC/AT, IBM PC/XT, PC-DOS 3.1, 640K RAM all true blue.
						   ^^^^^^^^^^^^^^^^^^^^^^^
						   Bellcore must have $$$.
> 
> Any suggestions on whether its an MSC problem, DOS problem or a bug [...]
>
> Bob Fair
> Bellcore/CHC

I ass_u_me that FORESEE is a large-model program, and is thus doing allocation
of "far" pointers.  (Calling _fmalloc() qualifies, regardless of overall
memory model.)

Large model memory allocation under MS-C 4.0 asks DOS for little pieces of
memory, (slowly I turn, step by step, block by block...) which are returned
to DOS only when free() is called.  (Or _ffree() if not large model.)

DOS does not reclaim these little blocks automatically.  Only the block that
contains the program's Program Segment Prefix (PSP) is automatically freed on
exit.  (Good thing, too, since to free your own code could be hazardous.)

Conclusion -- you are probably allocating some memory and not freeing it.

-- 
Chip Salzenberg		    Address: "{gatech,cbatt,akgua}!usfvax2!ateng!chip"
AT Engineering, Tampa, FL   Redress: "chips@usfvax2.UUCP"
"Use the Source, Luke!"	    My opinions do not necessarily agree with anything.