Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!vtserf!csugrad!briggs From: briggs@csugrad.cs.vt.edu (Allen Briggs) Newsgroups: comp.unix.bsd Subject: Re: free() - not working properly Message-ID: <BvE94t.Ix5@csugrad.cs.vt.edu> Date: 30 Sep 92 13:50:52 GMT References: <9227414.18251@mulga.cs.mu.OZ.AU> Organization: Virginia Tech Computer Science Dept, Blacksburg, VA Lines: 34 In article <9227414.18251@mulga.cs.mu.OZ.AU> johnp@mundil.cs.mu.OZ.AU (John Steve PETROU) writes: >I was wondering if anyone else has had the same problems as me with >free(). I'm not saying that what you're having are not problems, but... >If a process mallocs and frees memory durings its normal execution, I find >that ps -axv reports that the VSZ is always growing. > [...] I found the same thing with xgif, after increasing the size of an >image the VSZ increased as expected but wouldn't decrease when the image >was reduced. If the program is allocating ever-increasing amounts of memory, that is correct--the memory usage *must* increase. In fact, your program does just this. Even in the case of xgif that you cite, you might expect that the memory usage is reduced. You'd be right, but the free(3)ed blocks are simply marked as free while the actual memory space given to the process stays at it's maximum. Does anyone else have a problem with this strategy? It makes sense for short-lived processes (which do abound in Unix), but for applications that are up for long periods of time (like an X server) it can cause some problems. Is there a problem with calling sbrk(2) with a neg. value? What I'm saying is that your problem is in the design of the dynamic memory allocation strategy--not with the implementation. As long as the kernel doesn't have a memory leak... -allen -- Allen Briggs \ People hurry by so quickly briggs@csugrad.cs.vt.edu | Don't they hear the melodies Computer Science / In the chiming and the clicking Virginia Tech / And the laughing harmonies. (Joni Mitchell)