Memory debugger: Difference between revisions

Revision as of 00:42, 11 September 2021

Latest revision as of 14:11, 30 June 2025

(7 intermediate revisions by 6 users not shown)

Line 3:

{{Program execution}}

A '''memory debugger''' is a [[debugger]] for finding software memory problems such as [[memory leak]]s and [[buffer overflow]]s. These are due to [[Software bug|bugs]] related to the allocation and deallocation of [[dynamic memory]]. Programs written in languages that have [[Garbage collection (computer science)|garbage collection]], such as [[managed code]], might also need memory debuggers, e.g. for memory leaks due to "living" references in collections.

==Overview==

Memory debuggers work by monitoring memory access, allocations, and deallocation of memory. Many memory debuggers require applications to be recompiled with special dynamic memory allocation libraries, whose APIs are mostly compatible with conventional dynamic memory allocation libraries, or else use dynamic linking. [[Electric Fence]] is such a debugger which debugs memory allocation with [[malloc]]. Some memory debuggers (e.g. [[Valgrind]]) work by running the executable in a virtual machine-like environment, monitoring memory access, allocation and deallocation so that no recompilation with special memory allocation libraries is required.

Finding memory issues such as leaks can be extremely time -consuming as they may not manifest themselves except under certain conditions. Using a tool to detect memory misuse makes the process much faster and easier.<ref>{{cite web|url=http://www.computerworld.com/article/3003957/linux/review-5-memory-debuggers-for-linux-coding.html|access-date=August 24, 2017|title=Review: 5 memory debuggers for Linux coding|date=20 November 2015}}</ref>

As abnormally high memory utilization can be a contributing factor in [[software aging]], memory debuggers can help programmers to avoid [[software anomaly|software anomalies]] that would exhaust the computer system memory, thus ensuring high reliability of the software even for long [[run time (program lifecycle phase)|runtimes]].

==Comparison to static analyzer==

Some [[List of tools for static code analysis|static analysis tools]] can also help find memory errors. Memory debuggers operate as part of an application while it'sits [[Execution (computing)|running]] while [[static code analysis]] is performed by analyzing the code without executing it. These different techniques will typically find different instances of problems, and using them both together yields the best result.<ref>{{cite web|url=https://software.intel.com/en-us/inspector-user-guide-windows-dynamic-analysis-vs-static-analysis|access-date=August 24, 2017|title=Dynamic Analysis vs. Static Analysis}}</ref>

==List of memory debugging tools==

Line 29:

| Linux, Mac OS

| Free/open source (LLVM)

| C, C++., Rust

| Compile-time instrumentation (available in [[Clang]] and [[GNU Compiler Collection|GCC]]) and specialized library

|-

| [[Allinea Distributed Debugging Tool|Allinea DDT]]

| Linux, Blue Gene

| {{Proprietary}} commercial

| C, C++ and F90. Also for parallel programs on supercomputers

| Runtime - through dynamic linking

Line 40:

| [[AQtime]]

| Windows (Visual Studio, Embarcadero IDEs)

| {{Proprietary}} commercial

| .NET, C++, Java, Silverlight, JScript, VBScript<ref>{{Cite web |url=http://smartbear.com/products/qa-tools/application-performance-profiling/profiling-managed-code |title=ArchivedManaged copyCode - AQtime Pro &#124; SmartBear |access-date=2013-01-14 |archive-url=https://web.archive.org/web/20130919153515/http://smartbear.com/products/qa-tools/application-performance-profiling/profiling-managed-code |archive-date=2013-09-19 |url-status=dead }}</ref>

| Runtime

|-

Line 52:

| [[BoundsChecker]]

| Windows (Visual Studio)

| {{Proprietary}} commercial

| C++

| Runtime intercepts or compile-time

Line 70:

| [[Deleaker]]

| Windows (standalone, and plugins for Visual Studio, RAD Studio, Qt Creator, CLion)

| {{Proprietary}} commercial

| C++, .Net, Delphi

| Runtime intercepts

|-

| [[dmalloc]]

| {{Any}}

| Free/open source ([[ISC License]])

| C

| Compile-time override

Line 83:

| Android, Linux, Windows

| Free/open source (LGPL and BSD)

| {{Any}}

| Runtime intercepts

|-

| [[Electric Fence]]

| Unix

| {{GPL-lic|Free/open source (GPL)}}

| C, C++

| Compile-time override

Line 94:

| [[FASTMM4]]

| Windows

| {{GPL-lic|Free/open source (GPL)}}

| Delphi

| Compile-time override

Line 100:

| [[IBM Rational Purify]]

| Unix, Windows

| {{Proprietary}} commercial

| C++, Java, .NET

| Runtime

Line 106:

| [[Insure++]]

| Windows (Visual Studio plugin), Unix

| {{Proprietary}} commercial

| C, C++

| source code instrumentation

Line 112:

| [[Intel Inspector]]

| Windows (Visual Studio), Linux

| {{Proprietary}} commercial

| C, C++, Fortran

| Runtime

|-

| [[libcwd]]

| Linux (gcc)

| Free/open source

Line 129:

|-

| [[Memwatch]]

| {{Any}} (programming library)

| Free/open source

| C

Line 135:

|-

| [[mtrace]]

| {{varies|Various}}

| {{LGPL-lic|Free/open source (LGPL)}}

| GNU C library

| Built-in, outputs accesses

|-

| [[MTuner]]

| {{varies|Various}}

| {{Free}}

| C, C++

| Runtime intercepts, Link-time override (MSVC, Clang and GCC), Leak detection

Line 154:

| [[OLIVER]] (APT international)

| MVS, MVS/EXA, DOS/VSE

| {{Proprietary}} software

| IBM Assembler

| Runtime intercepts, Hypervisor - Type 2

Line 160:

| [[Rogue Wave Software|TotalView]]

| Unix, Mac OS X

| {{Proprietary}} commercial

| C, C++, Fortran

| Runtime

|-

| {{section link|Valgrind|Memcheck}}

| Linux, FreeBSD, Solaris/illumos, Mac OS, Android

| {{GPL-lic|Free/open source (GPL)}}

| {{Any}}

| Runtime intercepts

|-

| [[WinDbg]]

| Windows

| {{Proprietary}} freeware

| C, C++, .NET, Python

| Runtime