home *** CD-ROM | disk | FTP | other *** search
- 30-Jun-92 Mungwall 37.52 doc.
-
- Mungwall munges memory and watches for illegal FreeMem's.
- Mungwall is especially useful in combination with Enforcer.
- Output is either serial or parallel (mungwall.par).
-
- Since 37.49 MungWall, NAMETAG option tags each allocation with the name
- of the allocator. The new "MUNGLIST" program examines used memory areas
- for mungwall tag info, and outputs a list of who owns the various
- pieces of allocated memory, their sizes, etc. If you have used the
- NAMETAG option of MungWall, this list will include the name of the
- task or command that allocated the memory. Note that certain
- allocations belonging to your program may be displayed as belonging
- to another task (such as the task of a disk device that you
- locked a file on or accessed).
-
- Mungwall 37.51 adds an AvailMem wedge which reduces reported available
- memory by the size which Mungwall will add to any allocation. It also
- correct a problem which had caused the NAMETAG option to crash on a
- 68000.
-
- Mungwall 37.52 fixes Enforcer hits in task name comparisons and adds
- better A6 handling when calling the real memory functions.
-
- Memory munging:
-
- - Except when Enforcer is running, location 0 is set to $C0DEDBAD, i.e.
- programs referencing location zero will not f.e. find a null string.
-
- - On startup all free memory is munged with $ABADCAFE. If this number
- shows up, someone is referencing memory in the free list.
-
- - Except when MEMF_CLEAR is set, memory is pre-munged on allocation with
- $DEADFOOD. When this is used in an Enforcer report, the caller is
- allocating memory and doesn't initialize it before using it. Note that
- only memory which has a cookie attached will be pre-munged.
-
- - Memory is filled with $DEADBEEF before it is freed, encouraging
- programs reusing free'ed memory to crash.
-
- Memory watching:
-
- Mungwall places a magic cookie before the memory allocation.
- Along with a wall of bytes on either side of the allocation to keep an
- eye on the memory just before or after the allocation. If the
- memory wall is trashed, mungwall complains and shows the damaged area.
- If memory is trashed so bad that the cookie is completely gone, Mungwall
- will not consider it a walled memory allocation and lets it go. Changes
- are you'll be corrupting the memory list and/or overwriting other memory
- allocation and crash soon after that. If a mungwall hit occurs, memory
- will not be munged or free'ed, to give you a change to look at what was
- written there.
-
- Both null pointer FreeMem()'s and null sized Alloc/FreeMem()'s trigger
- mungwall. Mungwall also gets upset when a memoryblock is free'ed with a
- size different from the one used for allocating the memoryblock, and will
- say so. The integrity of the walls will be tested according to the size
- specified on allocation time, but will not be free'ed.
-
- Pointers passed to FreeMem() will be rejected if they are non-longword
- alligned. Thus possible catching bogus pointers otherwise left untouched
- by mungwall.
-
- Unless a specific task(s) is watched and that task leaves before mungwall
- does, mungwall will always lose some memory.
-
- NOTES:
-
- Other debugging tools which SetFunction() AllocMem() and/or
- FreeMem() and JSR to what they think is the old memory routine,
- should be run BEFORE mungwall. Mungwall needs to know the returnaddress
- of the initial caller. Running other debugging tools after mungwall
- will result in false reports about layers.library and invalid
- mungwall reports about the caller. The 'scratcher' for example must
- be run before mungwall, 'memoration' can be run afterwards, since it
- JMP's.
-
- When mungwall is being stopped, the walls around the original allocations
- which are not free'ed at that point, will never get free'ed, only the block
- within. Thus causing memory fragmentation and memoryloss.
-
- Memory allocations larger than 3 gigabytes will not be marked by mungwall.
-
-
-
- MUNGWALL [UPDATE] [[TASK name][WAIT]] [SNOOP] [NOSNOOP] [NOWAIT] [INFO]
- [MEGASTACK] [NAMETAG] [PRESIZE n] [POSTSIZE n] [FILLCHAR 0xXX]
-
- TASK name - Watch only the task(s), or all but the task(s) specified
- with 'name'. Multiple tasknames are indicated by placing
- a '|' between the names. If the names are preceeded by an
- exclamation mark, all tasks except the ones indicated are
- tracked. ALL is a reserved name, indicating all tasks
- should be tracked. Default ALL.
-
- PRESIZE - Size of wall before memory allocation in bytes. Minimum 4,
- maximum 64. Default 32.
-
- POSTSIZE - Size of wall after memory allocation in bytes. Minimum 4,
- maximum 64. The actual number of bytes after the allocation
- may vary slightly, since it's upped to the nearest longword.
- Default 32.
-
- FILLCHAR n - Character to build the memory wall with. Can be indicated
- both hexadecimal and decimal. Default 0xBB.
-
- SNOOP - Produce snoop compatible output. No snoop output is given
- for illegal FreeMem's. Default OFF. Layers AllocMem's and
- FreeMem's are never snooped. SNOOP is particulary useful
- in combination with TASK. Snoop output can be filtered
- with 'snoopstrip' to find the origin of memory loss.
-
- WAIT - Halt task causing a hit and wait for Ctrl-C. Make sure you
- - can issue a break to the task. WAIT can be used without
- specifying a specific taskname to watch. Default OFF.
-
- INFO - Show configuration information.
-
- MEGASTACK - Show 32 longwords of the stack whenever a hit/snoop occurs
-
- NAMETAG - Tag each allocation with allocating task or command's name
-
- UPDATE - Indicates an already running mungwall task should be up-
- dated with new parameters. Presize, postsize and fillchar
- can never be updated.
-
- The following are extra updating parameters.
-
- NOSNOOP - Turn snooping off.
-
- NOWAIT - No longer halt a task in case of an error.
-