A technique for finding storage allocation errors in C-language programs

Barach, David R.; Taenzer, David H.; Wells, Robert E.

doi:10.1145/988376.988379

Cited by 3 publications

(3 citation statements)

References 1 publication

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For application and system software, compiler-inserted program instrumentation (or simply compiler instrumentation) -where the compiler inserts special code into the program-undertest to monitor its execution -has emerged as a popular way for programmers to gain visibility into how their programs are operating. Programmers today can avail themselves of a variety of instrumentation-based dynamic-analysis tools, such as race detectors [3-5, 12-14, 18], memory checkers [1,8,17], cache simulators [2,20,25], call-graph generators [7,10], code-coverage analyzers [22,23], and performance and scalability profilers [9,16,24]. These tools generally operate as shadow computations -executing behind the scenes while the program-under-test runs.…”

Section: Extended Abstractmentioning

confidence: 99%

“…The code for CSI-cov, shown in Figure 1 in its entirety, is both short and simple. 1 In just 42 lines, the CSI framework implements this useful compiler-based tool as a simple C library. Without the CSI framework, a code-coverage tool based on compiler instrumentation would require considerably more development effort, as well as an understanding of the internals of the compiler.…”

Section: A Brief Tutorial On Csimentioning

confidence: 99%

See 1 more Smart Citation

The CSI Framework for Compiler-Inserted Program Instrumentation

Schardl

Denniston

Doucet

et al. 2018

Abstracts of the 2018 ACM International Conference on Measurement and Modeling of Computer Systems

View full text Add to dashboard Cite

The CSI framework [15] provides comprehensive static instrumentation that a compiler can insert into a program-under-test so that dynamic-analysis tools -memory checkers, race detectors, cache simulators, performance profilers, code-coverage analyzers, etc.can observe and investigate runtime behavior. Heretofore, tools based on compiler instrumentation would each separately modify the compiler to insert their own instrumentation. In contrast, CSI inserts a standard collection of instrumentation hooks into the program-under-test. Each CSI-tool is implemented as a library that defines relevant hooks, and the remaining hooks are "nulled" out and elided during either compile-time or link-time optimization, resulting in instrumented runtimes on par with custom instrumentation. CSI allows many compiler-based tools to be written as simple libraries without modifying the compiler, lowering the bar for the development of dynamic-analysis tools.We have defined a standard API for CSI and modified LLVM to insert CSI hooks into the compiler's internal representation (IR) of the program. The API organizes IR objects -such as functions, basic blocks, and memory accesses -into flat and compact ID spaces, which not only simplifies the building of tools, but surprisingly enables faster maintenance of IR-object data than do traditional hash tables. CSI hooks contain a "property" parameter that allows tools to customize behavior based on static information without introducing overhead. CSI provides "forensic" tables that tools can use to associate IR objects with source-code locations and to relate IR objects to each other.To evaluate the efficacy of CSI, we implemented six demonstration CSI-tools. One of our studies shows that compiling with CSI and linking with the "null" CSI-tool produces a tool-instrumented executable that is as fast as the original uninstrumented code. Another study, using a CSI port of Google's ThreadSanitizer, shows that the CSI-tool rivals the performance of Google's custom compiler-based

show abstract

Section: Extended Abstractmentioning

confidence: 99%

Section: A Brief Tutorial On Csimentioning

confidence: 99%

The CSI Framework for Compiler-Inserted Program Instrumentation

Schardl

Denniston

Doucet

et al. 2018

Abstracts of the 2018 ACM International Conference on Measurement and Modeling of Computer Systems

View full text Add to dashboard Cite

show abstract

“…This approach is often used in languages that allow unbounded pointers, like C and C++. Examples include malloc debug libraries (Barach et al, 1982), the GNU implementation of the C++ STL functionality, and the Microsoft Windows SDK debug libraries. As we argue in our concluding remarks, runtime monitoring tools complement our approach with a potential to locate more errors slightly later in the development cycle.…”

Section: Research Contextmentioning

confidence: 99%

A framework for the static verification of api calls

Spinellis

Λουρίδας

2007

Journal of Systems and Software

View full text Add to dashboard Cite

A number of tools can statically check program code to identify commonly encountered bug patterns. At the same time, programs are increasingly relying on external APIs for performing the bulk of their work: the bug-prone program logic is being fleshed-out, and many errors involve tricky subroutine calls to the constantly growing set of external libraries. Extending the static analysis tools to cover the available APIs is an approach that replicates scarce human effort across different tools and does not scale. Instead, we propose moving the static API call verification code into the API implementation, and distributing the verification code together with the library proper. We have designed a framework for providing static verification code together with Java classes, and have extended the FindBugs static analysis tool to check the corresponding method invocations. To validate our approach we wrote verification tests for 100 different methods, and ran FindBugs on 6.9 million method invocations on what amounts to about 13 million lines of production-quality code. In the set of 55 thousand method invocations that could potentially be statically verified our approach identified 800 probable errors.

show abstract

Garbage collecting the Internet

Sudi

Ringwood²

1998

ACM Comput. Surv.

View full text Add to dashboard Cite

Internet programming languages such as Java present new challenges to garbage-collection design. The spectrum of garbage-collection schema for linked structures distributed over a network are reviewed here. Distributed garbage collectors are classified first because they evolved from single-address-space collectors. This taxonomy is used as a framework to explore distribution issues: locality of action, communication overhead and indeterministic communication latency.

show abstract

A technique for finding storage allocation errors in C-language programs

Cited by 3 publications

References 1 publication

The CSI Framework for Compiler-Inserted Program Instrumentation

The CSI Framework for Compiler-Inserted Program Instrumentation

A framework for the static verification of api calls

Garbage collecting the Internet

Contact Info

Product

Resources

About