What if I don't free() all my dynamically allocated memory?

Anthony Scian afscian at violet.waterloo.edu
Mon Apr 10 11:22:39 AEST 1989


In article <8395 at xanth.cs.odu.edu> kremer at cs.odu.edu (Lloyd Kremer) writes:
>>In article <2367 at maccs.McMaster.CA> cs3b3aj at maccs.McMaster.CA (Stephen M. Dunn) writes:
>>>In article <2580 at ssc-vax.UUCP> dmg at ssc-vax.UUCP (David Geary) writes:
>>>[summary: can a program leave the freeing of memory to the OS (on the PC)]
>>YES
>If you halloc() a lot of memory and fail to hfree() it, at program exit you
>may very well be presented with the disheartening message:
>
>Memory allocation error
>Cannot load COMMAND, system halted
>
>[misconceptions about halloc/hfree]
>To sum up: is it OK not to free memory on a PC?  Yes, as long as you don't
>use halloc(), otherwise watch out!
The errors you experienced were from modifying memory outside the block
allocated to you. This IS a difficult thing to debug. Maybe this explanation
will clear things up.

When a .EXE program starts execution, it is given the largest contiguous
block of memory available. Most start-up code will calculate how much
the program requires minimally and resize the block to this size.
Through resizing of the first block and allocation of new blocks through
fmalloc/ffree & halloc/hfree MS-DOS can keep track of who owns what.
MS-DOS will release all the memory owned by a 'process' (really the owner
of the PSP). There are no problems with not freeing your memory unless
you are a TSR or you spawn other programs off which need memory. However,
if you managed to stomp on any of the important memory control blocks
owned by MS-DOS, termination of the program can result in Memory Allocation
Errors (always be thankful when it happens right after the program terminates,
if it things bubble awhile and then it happens you have an even tougher
debugging problem!)


//// Anthony Scian afscian at violet.uwaterloo.ca afscian at violet.waterloo.edu ////
"I can't believe the news today, I can't close my eyes and make it go away" -U2



More information about the Comp.lang.c mailing list