home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / windows / x / 14619 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  2.2 KB
  1. Path: sparky!uunet!mcsun!uknet!lsl!snail
  2. From: snail@lsl.co.uk
  3. Newsgroups: comp.windows.x
  4. Subject: Re: Memory leaks
  5. Message-ID: <1992Jul30.122716.2199@lsl.co.uk>
  6. Date: 30 Jul 92 11:27:16 GMT
  7. References: <9207291738.AA05158@mtesol>
  8. Organization: Laser-Scan Ltd., Cambridge
  9. Lines: 37
  10.  
  11. In article <9207291738.AA05158@mtesol>, sinan@mtesol.boeing.COM (Sinan Karasu) writes:
  12. > 
  13. >  When is a memory leak a memory leak. If I do many malloc's with
  14. > no dalloc's , does the memory remain leaked when the program exits?
  15. > Is the answer different in different OSs such as Sun,SCO etc... ?
  16. > Sinan
  17.  
  18. When a program starts it is given it's own stack space and it's own heap space.
  19. Memory is allocated in the heap space. When the program exits, the stack space
  20. and the heap space are passed back into the OS's hands. You do not leak
  21. memory this way. This is even true for MSDOS, since you only ever have one
  22. main program, and all TSRs should be well behaved and not grab memory and 
  23. leave it lying around. For UNIX and VMS you'll be OK. If you access memory
  24. outside the stack or heap or BSS space then you'll get a segmentation fault or
  25. access violation and you program will enter it's signal handler and probably
  26. die (ie: You'll know about it!)
  27.  
  28. The answer for MSDOS and GEMDOS/TOS (Atari ST) can be more complicated, since
  29. the program effectively
  30. has access to the whole memory of the computer, but can actually tell the
  31. OS that it only wants some of the memory, and gives it back to the OS. The
  32. program can then ask for more if it need more later (by doing a DOS level
  33. call rather than a malloc etc). What happens if the program does this and then
  34. exits I don't know (ie Is that last DOS level call freed? I don't think it is..
  35. I think you'd have to explicitly do another DOS level call). Anyway you don't
  36. use MSDOS or GEMDOS/TOS anyway do you?
  37.  
  38. On MSDOS if you access memory outside the heap/stack/bss areas then chances are
  39. you'll clobber one of the expansion cards or low memory and overwrite the
  40. CMOS RAM that configures the computer (yes I've done this too, with a rogue
  41. mouse driver program) and most likely hang the computer (RESET time)
  42.  
  43.  
  44. OK, thats enough, not exactly X WINDOWS is it?
  45.  
  46. Stephen Kellett
  47. snail@lsl.co.uk
  48.