home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD v1.2 / amidev_cd_12.iso / cdtv / cdtvtools-20 / debugtools / mungwall.doc < prev    next >
Text File  |  1992-02-06  |  6KB  |  124 lines
  1. 05-Feb-92 Mungwall 37.49 doc.
  2.  
  3. Mungwall munges memory and watches for illegal FreeMem's.
  4. Mungwall is especially useful in combination with Enforcer.
  5. Output is either serial or parallel (mungwall.par).
  6.  
  7. New (37.49) MungWAll NAMETAG option tags each allocation with the name
  8. of the allocator.  The new "MUNGLIST" program examines used memory areas
  9. for mungwall tag info, and outputs a list of who owns the various
  10. pieces of allocated memory, their sizes, etc.  If you have used the
  11. NAMETAG option of MungWall, this list will include the name of the
  12. task or command that allocated the memory.  Note that certain
  13. allocations belonging to your program may be displayed as belonging
  14. to another task (such as the task of a disk device that you
  15. locked a file on or accessed).
  16.  
  17. Memory munging:
  18.  
  19.  - Except when Enforcer is running, location 0 is set to $C0DEDBAD, i.e.
  20.    programs referencing location zero will not f.e. find a null string.
  21.  
  22.  - On startup all free memory is munged with $ABADCAFE. If this number
  23.    shows up, someone is referencing memory in the free list.
  24.  
  25.  - Except when MEMF_CLEAR is set, memory is pre-munged on allocation with
  26.    $DEADFOOD. When this is used in an Enforcer report, the caller is
  27.    allocating memory and doesn't initialize it before using it. Note that
  28.    only memory which has a cookie attached will be pre-munged.
  29.  
  30.  - Memory is filled with $DEADBEEF before it is freed, encouraging
  31.    programs reusing free'ed memory to crash.
  32.  
  33. Memory watching:
  34.  
  35. Mungwall places a magic cookie before the memory allocation.
  36. Along with a wall of bytes on either side of the allocation to keep an
  37. eye on the memory just before or after the allocation. If the
  38. memory wall is trashed, mungwall complains and shows the damaged area.
  39. If memory is trashed so bad that the cookie is completely gone, Mungwall
  40. will not consider it a walled memory allocation and lets it go. Changes
  41. are you'll be corrupting the memory list and/or overwriting other memory
  42. allocation and crash soon after that. If a mungwall hit occurs, memory
  43. will not be munged or free'ed, to give you a change to look at what was
  44. written there.
  45.  
  46. Both null pointer FreeMem()'s and null sized Alloc/FreeMem()'s trigger
  47. mungwall. Mungwall also gets upset when a memoryblock is free'ed with a
  48. size different from the one used for allocating the memoryblock, and will
  49. say so. The integrity of the walls will be tested according to the size
  50. specified on allocation time, but will not be free'ed.
  51.  
  52. Pointers passed to FreeMem() will be rejected if they are non-longword
  53. alligned. Thus possible catching bogus pointers otherwise left untouched
  54. by mungwall.
  55.  
  56. Unless a specific task(s) is watched and that task leaves before mungwall
  57. does, mungwall will always lose some memory.
  58.  
  59. NOTES:
  60.  
  61. Other debugging tools which SetFunction() AllocMem() and/or
  62. FreeMem() and JSR to what they think is the old memory routine,
  63. should be run BEFORE mungwall. Mungwall needs to know the returnaddress
  64. of the initial caller. Running other debugging tools after mungwall
  65. will result in false reports about layers.library and invalid
  66. mungwall reports about the caller. The 'scratcher' for example must
  67. be run before mungwall, 'memoration' can be run afterwards, since it
  68. JMP's.
  69.  
  70. When mungwall is being stopped, the walls around the original allocations
  71. which are not free'ed at that point, will never get free'ed, only the block
  72. within. Thus causing memory fragmentation and memoryloss.
  73.  
  74. Memory allocations larger than 3 gigabytes will not be marked by mungwall.
  75.  
  76.  
  77.  
  78. MUNGWALL [UPDATE] [[TASK name][WAIT]] [SNOOP] [NOSNOOP] [NOWAIT] [INFO]
  79.          [MEGASTACK] [NAMETAG] [PRESIZE n] [POSTSIZE n] [FILLCHAR 0xXX]
  80.  
  81. TASK name   - Watch only the task(s), or all but the task(s) specified
  82.               with 'name'. Multiple tasknames are indicated by placing
  83.               a '|' between the names. If the names are preceeded by an
  84.               exclamation mark, all tasks except the ones indicated are
  85.               tracked. ALL is a reserved name, indicating all tasks
  86.               should be tracked. Default ALL.
  87.  
  88. PRESIZE     - Size of wall before memory allocation in bytes. Minimum 4,
  89.               maximum 64. Default 32.
  90.  
  91. POSTSIZE    - Size of wall after memory allocation in bytes. Minimum 4,
  92.               maximum 64. The actual number of bytes after the allocation
  93.               may vary slightly, since it's upped to the nearest longword.
  94.               Default 32.
  95.  
  96. FILLCHAR n  - Character to build the memory wall with. Can be indicated
  97.               both hexadecimal and decimal. Default 0xBB.
  98.  
  99. SNOOP       - Produce snoop compatible output. No snoop output is given
  100.               for illegal FreeMem's. Default OFF. Layers AllocMem's and
  101.               FreeMem's are never snooped. SNOOP is particulary useful
  102.               in combination with TASK. Snoop output can be filtered
  103.               with 'snoopstrip' to find the origin of memory loss.
  104.  
  105. WAIT        - Halt task causing a hit and wait for Ctrl-C. Make sure you
  106.             - can issue a break to the task. WAIT can be used without
  107.               specifying a specific taskname to watch. Default OFF.
  108.  
  109. INFO        - Show configuration information.
  110.  
  111. MEGASTACK   - Show 32 longwords of the stack whenever a hit/snoop occurs
  112.  
  113. NAMETAG     - Tag each allocation with allocating task or command's name
  114.  
  115. UPDATE      - Indicates an already running mungwall task should be up-
  116.               dated with new parameters. Presize, postsize and fillchar
  117.               can never be updated.
  118.  
  119. The following are extra updating parameters.
  120.  
  121. NOSNOOP     - Turn snooping off.
  122.  
  123. NOWAIT      - No longer halt a task in case of an error.
  124.