home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / c / 18743 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.1 KB
  1. Path: sparky!uunet!spool.mu.edu!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!mouse
  2. From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Problems freeing memory using "free"
  5. Keywords: malloc,free,panic.
  6. Message-ID: <1992Dec21.171523.18080@thunder.mcrcim.mcgill.edu>
  7. Date: 21 Dec 92 17:15:23 GMT
  8. References: <BzH3uB.KnI@ccu.umanitoba.ca>
  9. Organization: McGill Research Centre for Intelligent Machines
  10. Lines: 39
  11.  
  12. In article <BzH3uB.KnI@ccu.umanitoba.ca>, ies@access.mbnet.mb.ca (Integrated Engineering Software) writes:
  13.  
  14. > When is dynamically allotted memory using c(m)alloc freed after
  15. > calling "free"?
  16.  
  17. By the time free returns, the memory has been freed and must not be
  18. accessed again.  Most implementations will permit the memory to
  19. continue to exist for some indeterminate time after free() returns;
  20. some will even leave the former contents undisturbed for a while.  You
  21. cannot depend on either of these.
  22.  
  23. > Using os_view() on a SGI, I am able to monitor the RAM available
  24. > before a call to c(m)alloc and after a call to free().  The OS
  25. > indicates that the dynamic memory has been allotted from the
  26. > available RAM(a test problem) and but then does not release the
  27. > allotted memory even after a call to free.
  28.  
  29. This makes it an OS question, and as such it really belongs in the
  30. appropriate OS-specific group, comp.sys.sgi or some such.
  31.  
  32. Most UNIXish systems' implementations of malloc never return memory to
  33. the OS; memory being free simply means that it is available for further
  34. calls to malloc.  Whether another call to malloc will allocate some or
  35. all of the same memory is implementation-dependent and cannot be
  36. counted upon either way.
  37.  
  38. > The available RAM is critical for my app, but future malloc's will
  39. > allot memory from the swap space which I do not want to access.
  40.  
  41. I'm not sure what the problem is here.  If you allocated a block and
  42. freed it, and future mallocs don't return it, the system will push
  43. those pages to swap because you're not accessing them, thus letting you
  44. keep something else in-core instead.  If future mallocs do return that
  45. same memory, no problem.
  46.  
  47.                     der Mouse
  48.  
  49.                 mouse@larry.mcrcim.mcgill.edu
  50.