Diamond, a D Memory Debugger (and profiler)

Extrawurst spam at extrawurst.org
Mon Jun 22 00:55:37 PDT 2009


Vladimir Panteleev wrote:
> I've been working on this project on and off for over a year, and 
> presented it as part of my graduation thesis on memory management in D. 

Sounds great, is it possible to read the aforementioned thesis too ?

> I think I'm done working on it for a while (due to many other projects 
> begging for attention), and even though there's still things that could 
> be finished or improved, it's quite useful as it is now.
> 
> Diamond is a post-mortem memory debugger and profiler. It is composed of 
> two parts:
>  * a module, which should be imported before any other modules in the 
> project to be debugged
>  * a memory log analyzer, which allows inspecting generated memory logs
> 
> The module logs all memory operations to a file, as well as periodic 
> memory snapshots (before garbage collects). Some logging options are 
> configurable.
> 
> Diamond aims to facilitate debugging memory leaks (data referenced by 
> bogus pointers), memory corruption and other problems. It was written 
> for D1 (both Phobos and Tango), D2 support is untested at best.
> 
> Runtime module features:
>  * logs all memory events, with timestamps and call stacks
>  * exports C functions, allowing debuggee to log memory maps or 
> snapshots at any time, as well as log text comments
>  * has optional memory debugging features, like checking free calls and 
> stomping on deallocated memory
> 
> Log analyzer features:
>  * uses map files to display symbols in call stacks
>  * can seek through the log file, allowing to examine the application 
> state at different points in time
>  * can display "top allocators" - call stacks that allocated most bytes
>  * can filter memory events by address range
>  * can display a visual "memory map" [1] (useful for quickly finding 
> large areas the GC shouldn't be scanning for pointers)
>  * can search for references (pointers) to a certain memory range
>  * can dump a region of memory to screen
> 
> Things still to be done:
>  * documentation
>  * more type information (by hooking higher-level allocators)
>  * dumping data segment and thread stacks (currently only the heap is 
> dumped)
>  * more runtime library options
> 
> Project homepage:
> http://dsource.org/projects/diamond/
> 
> [1] 
> http://dump.thecybershadow.net/36ee988fc564aa9ab5529d43662eec81/0000062E.png 
> 
> 


More information about the Digitalmars-d-announce mailing list