imported>OAbot: Open access bot: url-access updated in citation with #oabot.

2025-05-23T21:08:39Z

Open access bot: url-access updated in citation with #oabot.

New page

{{Short description|Analysis of software performed when running a program}}
{{More citations needed|date=February 2009}}
{{Program execution}}

'''Dynamic program analysis''' is the act of [[Program analysis (computer science)|analyzing software]] that involves executing a [[computer program|program]] {{endash}} as opposed to [[static program analysis]], which does not execute it.

Analysis can focus on different aspects of the software including but not limited to: [[behavior]], [[test coverage]], [[software performance|performance]] and [[security]].

To be effective, the target program must be executed with sufficient test inputs<ref>{{Cite journal|last1=Khatiwada|first1=Saket|last2=Tushev|first2=Miroslav|last3=Mahmoud|first3=Anas|date=2018-01-01|title=Just enough semantics: An information theoretic approach for IR-based software bug localization|url=https://linkinghub.elsevier.com/retrieve/pii/S0950584916302269|journal=[[Information and Software Technology]]|language=en|volume=93|pages=45–57|doi=10.1016/j.infsof.2017.08.012|url-access=subscription}}</ref> to address the ranges of possible inputs and outputs. [[Software testing]] measures, such as [[code coverage]], and tools such as [[mutation testing]], are used to identify where testing is inadequate.

== Types ==

=== Functional testing ===
{{main|Software testing}}

Functional testing includes relatively common [[computer programming|programming]] techniques such as [[unit testing]], [[integration testing]] and [[system testing]].<ref>{{cite book |last1=Myers, G. J. |title=The Art of Software Testing |date=1979 |publisher=John Wiley and Sons.|author1-link=Glenford Myers }}</ref>

=== Code coverage ===

Computing the [[code coverage]] of a test identifies code that is not tested; not covered by a test.

Although this analysis identifies code that is not tested it does not determine whether tested coded is ''adequately'' tested. Code can be executed even if the tests do not actually verify correct behavior.

* [[Gcov]] is the [[GNU]] source code coverage program.
* [[VB Watch]] injects dynamic analysis code into Visual Basic programs to monitor [[code coverage]], call stack, execution trace, instantiated objects and variables.

=== Dynamic testing ===
{{main|Dynamic testing}}

Dynamic testing involves executing a program on a set of test cases.

=== Memory error detection ===

* [[AddressSanitizer]]: Memory error detection for Linux, [[macOS]], Windows, and more. Part of [[LLVM]].
* [[BoundsChecker]]: Memory error detection for Windows based applications. Part of [[Micro Focus]] [[DevPartner]].
* [[Dmalloc]]: Library for checking memory allocation and leaks. Software must be recompiled, and all files must include the special C header file dmalloc.h.
* [[Intel Inspector]]: Dynamic memory error debugger for C, C++, and Fortran applications that run on [[Windows]] and [[Linux]].
* [[IBM Rational Purify|Purify]]: Mainly [[storage violation|memory corruption]] detection and memory leak detection.
* [[Valgrind]]: Runs programs on a virtual processor and can detect memory errors (e.g., misuse of [[malloc]] and [[Free (programming)|free]]) and [[race conditions]] in [[Multithreading (software)|multithread]] programs.

=== Fuzzing ===
{{main|Fuzzing}}
Fuzzing is a testing technique that involves executing a program on a wide variety of inputs; often these inputs are randomly generated (at least in part). [[Fuzzing#Types|Gray-box fuzzers]] use code coverage to guide input generation.

=== Dynamic symbolic execution ===
{{main|Concolic testing}}

Dynamic symbolic execution (also known as ''DSE'' or concolic execution) involves executing a test program on a concrete input, collecting the path constraints associated with the execution, and using a [[constraint solver]] (generally, an [[SMT solver]]) to generate new inputs that would cause the program to take a different control-flow path, thus increasing code coverage of the test suite.<ref>{{Cite journal |last1=Chen |first1=Ting |last2=Zhang |first2=Xiao-song |last3=Guo |first3=Shi-ze |last4=Li |first4=Hong-yuan |last5=Wu |first5=Yue |date=2013-09-01 |title=State of the art: Dynamic symbolic execution for automated test generation |url=https://www.sciencedirect.com/science/article/pii/S0167739X12000398 |journal=Future Generation Computer Systems |series=Including Special sections: Cyber-enabled Distributed Computing for Ubiquitous Cloud and Network Services & Cloud Computing and Scientific Applications — Big Data, Scalable Analytics, and Beyond |language=en |volume=29 |issue=7 |pages=1758–1773 |doi=10.1016/j.future.2012.02.006 |issn=0167-739X|url-access=subscription }}</ref> DSE can be considered a type of [[#Fuzzing|fuzzing]] ("white-box" fuzzing).

=== Dynamic data-flow analysis ===

Dynamic data-flow analysis tracks the flow of information from ''sources'' to ''sinks''. Forms of dynamic data-flow analysis include dynamic taint analysis and even [[#Dynamic symbolic execution|dynamic symbolic execution]].<ref>{{Cite book |last1=Chen |first1=Ju |last2=Han |first2=Wookhyun |last3=Yin |first3=Mingjun |last4=Zeng |first4=Haochen |last5=Song |first5=Chengyu |last6=Lee |first6=Byoungyoung |last7=Yin |first7=Heng |last8=Shin |first8=Insik |date=2022 |title={SYMSAN}: Time and Space Efficient Concolic Execution via Dynamic Data-flow Analysis |url=https://www.usenix.org/conference/usenixsecurity22/presentation/chen-ju |language=en |pages=2531–2548 |isbn=978-1-939133-31-1}}</ref><ref>{{Cite book |last1=Chang |first1=Walter |last2=Streiff |first2=Brandon |last3=Lin |first3=Calvin |title=Proceedings of the 15th ACM conference on Computer and communications security |chapter=Efficient and extensible security enforcement using dynamic data flow analysis |date=2008-10-27 |chapter-url=https://doi.org/10.1145/1455770.1455778 |series=CCS '08 |location=New York, NY, USA |publisher=Association for Computing Machinery |pages=39–50 |doi=10.1145/1455770.1455778 |isbn=978-1-59593-810-7|s2cid=6888893 }}</ref>

=== Invariant inference ===
[[Daikon (system)|Daikon]] is an implementation of dynamic invariant detection. Daikon runs a program, observes the values that
the program computes, and then reports properties that were true over the observed executions, and thus likely true over all executions.

=== Security analysis ===
Dynamic analysis can be used to detect security problems.
* [[IBM Rational AppScan]] is a suite of application security solutions targeted for different stages of the development lifecycle. The suite includes two main dynamic analysis products: IBM Rational AppScan Standard Edition, and IBM Rational AppScan Enterprise Edition. In addition, the suite includes IBM Rational AppScan Source Edition—a static analysis tool.

=== Concurrency errors ===
* [[Parasoft]] [[Jtest]] uses runtime error detection to expose defects such as [[race conditions]], exceptions, resource and memory leaks, and security attack vulnerabilities.
* [[Intel Inspector]] performs run-time threading and memory error analysis in Windows.
* [[Parasoft]] [[Insure++]] is a runtime memory analysis and error detection tool. Its Inuse component provides a graphical view of memory allocations over time, with specific visibility of overall heap usage, block allocations, possible outstanding leaks, etc.
* [[Google's]] Thread Sanitizer is a data race detection tool. It instruments [[LLVM]] IR to capture racy memory accesses.

=== Program slicing ===
{{main|Program slicing}}
For a given subset of a program’s behavior, program slicing consists of reducing the program to the minimum form that still produces the selected behavior. The reduced program is called a “slice” and is a faithful representation of the original program within the domain of the specified behavior subset.
Generally, finding a slice is an unsolvable problem, but by specifying the target behavior subset by the values of a set of variables, it is possible to obtain approximate slices using a data-flow algorithm. These slices are usually used by developers during debugging to locate the source of errors.

=== Performance analysis ===

Most [[list of performance analysis tools|performance analysis tools]] use dynamic program analysis techniques.{{Citation needed|date=January 2008}}

== Techniques ==

Most dynamic analysis involves [[Instrumentation (computer programming)|instrumentation]] or transformation.

Since instrumentation can affect runtime performance, interpretation of test results must account for this to avoid misidentifying a performance problem.

=== Examples ===

DynInst is a runtime code-patching library that is useful in developing dynamic program analysis probes and applying them to compiled executables. Dyninst does not require [[source code]] or recompilation in general, however, non-stripped executables and executables with debugging symbols are easier to instrument.

[https://maierfelix.github.io/Iroh/ Iroh.js] is a runtime code analysis library for [[JavaScript]]. It keeps track of the code execution path, provides runtime listeners to listen for specific executed code patterns and allows the interception and manipulation of the program's execution behavior.

== See also ==
* [[Abstract interpretation]]
* [[Daikon (system)|Daikon]]
* [[Dynamic load testing]]
* [[Profiling (computer programming)]]
* [[Runtime verification]]
* [[Program analysis (computer science)]]
* [[Static code analysis]]
* [[Time Partition Testing]]

== References ==
{{Reflist}}

{{Software testing}}

[[Category:Dynamic program analysis| ]]
[[Category:Program analysis]]
[[Category:Software testing]]

Dynamic program analysis - Revision history

imported>OAbot: Open access bot: url-access updated in citation with #oabot.