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.