Memory debugger: Difference between revisions

Revision as of 09:32, 11 November 2021

Latest revision as of 14:11, 30 June 2025

(6 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

|-

Line 41:

| 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 76:

| [[dmalloc]]

| {{Any}}

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

| C

| Compile-time override

Line 116:

| Runtime

|-

| [[libcwd]]

| Linux (gcc)

| Free/open source

Line 148:

| [[Oracle Solaris Studio]] (formerly Sun Studio Runtime Checking)

| Linux, Solaris

| {{Proprietary}} freeware

| C, C++, Fortran

|

Line 165:

|-

| {{section link|Valgrind|Memcheck}}

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

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

| {{Any}}

| Runtime intercepts

|-