|Logo by McFly |
(anonymous IP: 188.8.131.52,0)
Total files: 4326
Full index file
Recent index file
Support the site
[Show comments] [Show snapshots] [Show videos] [Show content] [Show crashlogs]
This port was requested by Raziel, so, enjoy!(?) /spot Author: Markus Wolf Web: http://www.murkymind.de Version: 1.0 (20-nov-2006) The "memtrace" include files provides overview over dynamic memory allocation and deallocation for C/C++ code. A C++ compiler is required. It is intended for debugging and should be excluded (deactivated) for final project compilation. Files: "memtrace.h" : The only file to include into a project (include file tree) "memtrace_internal.h" : "MemTrace" class definition, "MemTrace" configuration via preprocessor directives, method descriptions "memtrace_internal.cpp" : "MemTrace" methods, must be compiled as separat object so a single global ("extern") instance can be used for a whole project How to use: ----------- - Edit the preprocessor configuration in "memtrace_internal.h" to your needs. - Compile "memtrace_internal.cpp" as separate object. It includes the one and only instance "memtrace" of class "MemTrace". - Include "memtrace.h" in the project where allocation should be watched in the following code. You don't have to change any code in your project. "memtrace.h" defines an external reference to the "memtrace" instance. - Link the "memtrace_internal.cpp" compiled object to your project when compiling. What it does: ---------------- - Watching your (de)allocations with file name and line of the appropriate statement in your code, finding memory leaks. - The "memtrace" instance has tables. Each allocation in your project creates a table entry. Which table is used, depends on the way of allocation: "new", "new", "malloc" - Each deallocation tries to delete the entry from the appropriate list, which may be successful or not. - Actions and errors can be logged to a stream of choice. - prints and logs the location of the (de)allocation action (file, line) - If entries are left in the table at program end, these are potential memory leaks, which means one of the following: * memory block is not deallocated * illegal deallocations were used for the allocation type ("free"/"delete"/"delete" mixing) * "memtrace" was locked during (de)allocation and was unable to trace -> not a memory leak - can check if a byte range (with address) is within allocated space registered in a list (via separate function call). Note: ----- - In order to start tracing memory (de)allocation, the "memtrace" instance must be "unlocked"! - Read the *.h files.