DDDebug is a collection of debugging tools which contains several modules: a memory profiler, a thread viewer, a module viewer and an enhanced exception handler. DDDebug can be integrated easily into your Delphi projects, either using its integrated graphical user interface or its API.

The memory profiler traces memory allocations, recognizes the type of allocation (whether it has been done because of creating an object, string, array or record) and provides up to date information about memory usage and statistics. Unlike other solutions it does support packages, is independent of any specific compiler switches and provides immediate feedback.

In a nutshell, the following features are implemented:

recognizes objects, strings, arrays and records
supports packages
supports profiling of multiple threads
call stack retrieval
uses standard MAP files
independent of compiler switches
integrated GUI for monitoring and debugging
easy to use; almost no special requirements
support for wait chain traversal
detection of thread deadlocks
detection of premature freed memory

Using DDDebug in your projects is easy: adding the unit DDDMainForm to the uses clause of your project is almost all you have to do in order to integrate it into your project. It is recommended to use the applied GUI to monitor memory allocations. The GUI gives you full control about almost any aspect of the memory profiler.

DDDMainFormThe form consists of a list view displaying allocated blocks of memory along with some details for each entry, a label summarizing the list views entries as well as some check boxes and buttons comprising the most frequent used functions. The items of the list view can be ordered in ascending and descending order by clicking on the appropriate column-header. The current order is indicated by a small arrow as shown for the column “ID” in the above screen shot. Select the check box “Activate” to activate resp. deactivate the memory profiler as well as the check box “Live” to automatically update the list view. For multi threaded and/or time consuming operations, it is recommended to deactivate this feature. If you do not select “Live”, you have to update it manually by clicking the button “Update”. The button “Clear” discards all entries.

You can see the address of each item, its size, the ID of the thread, which allocated the specific block of memory, the kind of memory allocation, the name of the package, which contains the specific type as well as some additional information specific to each type.

As you can see, the profiler distinguishes between several kinds of memory allocations:

mtObject: an object has been allocated
mtString: a string has been allocated
mtArray: an array has been allocated
mtRecord: a record has been allocated
mtUnknown: type could not be recognized
The content of the column “Data” depends on the recognized type:

the class name of the object being allocated
the reference count, length and content of the string
the reference count and length of the array
the name of the type of record being allocated
DDDCallStack1Double-click on any item for detailed information of the selected entry. A new dialog “DDDebug Allocation” will be displayed which provides several tab sheets containing in-depth-information. While the first one “Details” displays the same information already shown within the list view the other tab sheets contain much more details regarding the selected block of memory.

The tab sheet “CallStack” is probably of most interest and is shown within the screen shot to the left. One can see which flow of code has been executed leading to the allocation of the selected item.

Only for V.I.P