home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / amiga / programm / 12282 < prev    next >
Encoding:
Text File  |  1992-08-13  |  2.4 KB  |  50 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!stanford.edu!ames!haven.umd.edu!wam.umd.edu!kovert
  3. From: kovert@wam.umd.edu (Todd Kover)
  4. Subject: Re: Program Fragmenting Memory
  5. Message-ID: <1992Aug13.202314.9393@wam.umd.edu>
  6. Sender: usenet@wam.umd.edu (USENET News system)
  7. Nntp-Posting-Host: rac2.wam.umd.edu
  8. Organization: Insufficient Memory Software
  9. References: <1992Aug9.023203.7467@ariel.ec.usf.edu>
  10. Date: Thu, 13 Aug 1992 20:23:14 GMT
  11. Lines: 37
  12.  
  13. In article <1992Aug9.023203.7467@ariel.ec.usf.edu> stelmack@eggo.tmc.edu (Gregory M. Stelmack) writes:
  14. >My latest project has been fragmenting memory, and leaving two small chunks
  15. >behind. Running MungWall & MungList (thanks for Sushi!) reveals two tiny
  16. >chunks unfreed by my task -- sizes $0a and $a8. Anyway, I wrote my own 
  17. >wrappers for AllocMem and FreeMem that track the size and location of my
  18. >allocations, and replaced all my calls with these wrappers (searching every
  19. >source file to make sure I got them all). When I run with these, I still
  20. >lose memory, but all my Allocs are properly matched by same-sized Frees
  21. >(and MungWall does not complain). Also, neither address for the fragments
  22. >matches any of my allocations.
  23. >
  24. >So, does anyone know of anything that might be causing this? I am using
  25. >SAS/C 5.10b, and will call SAS Monday to see if there might be something
  26. >with their startup/shutdown code, but in the meantime am asking here.
  27. >Any ideas? Anyone know of any other tools that might help me track this
  28. >down?
  29.  
  30. I don't know what's causing it, but I ran into a similar problem when 
  31. writing a shared library.  (In my case, I took an include file in all of
  32. my source files, and #define'd AllocMem(x,y) AllocMemWrap(x,y) and 
  33. FreeMem(x,y) FreeMemWrap(x,y) and #undef's them in front of the actual
  34. function definitions).
  35.  
  36. I ran into the exact same problem.  Once I implemented these wrappers
  37. (and changed nothing else) there was no more fragmentation.  (Many many
  38. calls to all aspects of the library never yielded a problem, (naturally
  39. including the situations that originally did).
  40.  
  41. I'm using 5.10a, though, so I thought it may have something to do with that.
  42. Perhaps not, though.
  43.  
  44. -Todd
  45. -- 
  46. /* Todd Kover // [ #include  <std/disclaimer.h> ]  "Murphy's Law of Dating II:
  47.             \X/  [ Internet: kovert@wam.umd.edu ]   If you like her, she lives
  48. CIS: 70621,2376  [ Fido: 1:109/447 & 1:261/5016 ]   in a different state."
  49.           "Profanity is the language that all programmers know Best."       */
  50.