Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!inmos!nathan@elberton.inmos.co.uk
From: nathan@elberton.inmos.co.uk (Nathan Sidwell)
Newsgroups: comp.lang.c
Subject: Re: Question about malloc() and free()
Message-ID: <10274@ganymede.inmos.co.uk>
Date: 4 Sep 90 11:31:03 GMT
References: <1990Aug27.184058.1936@everexn.uucp> <714.26dd34df@iccgcc.decnet.ab.com> <2223@idunno.Princeton.EDU> <1990Aug31.005355.17898@mlb.semi.harris.com>
Sender: news@inmos.co.uk
Reply-To: nathan@inmos.co.uk (Nathan Sidwell)
Organization: INMOS Limited, Bristol, UK.
Lines: 46

In article <1990Aug31.005355.17898@mlb.semi.harris.com> del@thrush.mlb.semi.harris.com (Don Lewis) writes:
>Then the program goes into serious page fault mode for about 45
>minutes.  I don't know what it does during this time, but I'd be willing
>to bet that it is walking the data structure, freeing all the bits and
>pieces of memory it has malloc'ed along the way.  Finally it calls
>exit() which fflush's the rest of the output data.
>
>It sure would be considerate if this program just called exit()
>instead of wasting my time and a lot of cpu cycles doing something
>totally useless.  I'd even be happy with a strategically placed
>fflush() so that I could send the process a well deserved "kill -9".
>

While I agree that it would be more considerate of the program to just
exit (in this case), IMHO I think it a good idea to free malloc'd space
_during_ a program run (especially in an interactive program).
Also, during debugging, I explicitly free
blocks, so I can see if any are left that I've forgotten about.

One problem I have found is that the implementation of malloc I had
(this is MS C 5.1) was seriously flawed for a VM machine (OS/2). The problem
only came to light when the software was being used by users. After
several images had been read in, the machine started thrashing continuously.
I had explicitly prevented the program from slurping in more than X bytes of
total image, and figured that if it segment faulted it would do so only when
accessing the swapped out image etc. (OS/2 swaps whole segments, not pages.)

It turned out that [because of the way I had built the windowing system] every
mouse event causing a window notification, caused memory to be malloc'd and
free'd. Malloc would run through its linked list of empty blocks to find
one which fitted -- thereby touching every segment allocated. The clock
display was updated every two seconds, thereby guaranteeing a thrash
on this timescale.

I supplied my own malloc which kept a list of segments in a table, with enough
information in it to work out whether it was worth while examining a segment
for a possible empty block. This gave the additional win that I could remove
the debug code which checked that I was freeing blocks I'd actually
malloc'd :-)

I don't know if this is just a one off, but I would suspect other
implementations to suffer the same.

Nathan Sidwell, INMOS Ltd, UK         JANET:    nathan@uk.co.inmos
Generic disclaimer applies            UUCP:     ukc!inmos!nathan
My indicision is final (I think)      INTERNET: nathan@inmos.com