Analysis of pointers and structures

Chase, David; Wegman, Mark N.; Zadeck, F. Kenneth

doi:10.1145/989393.989429

Cited by 116 publications

(79 citation statements)

References 26 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In case of a positive answer, the general aim is to study whether this type of representation increases the speed of the reasoning mechanism, and why not -its accuracy. With the same purpose, we refer to a possible integration with the technique in [38] that handles point-to graphs via a stack-based algorithm for fixedpoint computations.…”

Section: Discussionmentioning

confidence: 99%

See 1 more Smart Citation

On the verification of SCOOP programs

Caltais

Meyer

2017

Science of Computer Programming

View full text Add to dashboard Cite

In this paper we focus on the development of a toolbox for the verification of programs in the context of SCOOP -an elegant concurrency model, recently formalized based on Rewriting Logic (RL) and Maude. SCOOP is implemented in Eiffel and its applicability is demonstrated also from a practical perspective, in the area of robotics programming. Our contribution consists in devising and integrating an alias analyzer and a Coffman deadlock detector under the roof of the same RL-based semantic framework of SCOOP. This enables using the Maude rewriting engine and its LTL model-checker "for free", in order to perform the analyses of interest. We discuss the limitations of our approach for model-checking deadlocks and provide solutions to the state explosion problem. The latter is mainly caused by the size of the SCOOP formalization which incorporates all the aspects of a real concurrency model. On the aliasing side, we propose an extension of a previously introduced alias calculus based on program expressions, to the setting of unbounded program executions such as infinite loops and recursive calls. Moreover, we devise a corresponding executable specification easily implementable on top of the SCOOP formalization. An important property of our extension is that, in non-concurrent settings, the corresponding alias expressions can be over-approximated in terms of a notion of regular expressions. This further enables us to derive an algorithm that always stops and provides a sound over-approximation of the "may aliasing" information, where soundness stands for the lack of false negatives.

show abstract

Section: Discussionmentioning

confidence: 99%

“…Hence, the rewriting process finishes with a sound over-approximation reg(r 2 , r 4 ) replacing the current alias relation (cf. Lemma 7), defined precisely as in (38).…”

Section: The K-machinery By Examplementioning

confidence: 99%

On the verification of SCOOP programs

Caltais

Meyer

2017

Science of Computer Programming

View full text Add to dashboard Cite

show abstract

“…• Summarized heap graphs are stored by associating each graph node with a boolean predicate indicating whether it is a summary node representing more than one concrete heap location [15]. Observe that summary nodes may result in spurious cycles in the graph if two objects represented by a summary node are connected by an edge.…”

Section: Summarizationmentioning

confidence: 99%

Heap Abstractions for Static Analysis

Kanvar

Khedker

2016

ACM Comput. Surv.

View full text Add to dashboard Cite

Heap data is potentially unbounded and seemingly arbitrary. As a consequence, unlike stack and static memory, heap memory cannot be abstracted directly in terms of a fixed set of source variable names appearing in the program being analysed. This makes it an interesting topic of study and there is an abundance of literature employing heap abstractions. Although most studies have addressed similar concerns, their formulations and formalisms often seem dissimilar and some times even unrelated. Thus, the insights gained in one description of heap abstraction may not directly carry over to some other description. This survey is a result of our quest for a unifying theme in the existing descriptions of heap abstractions. In particular, our interest lies in the abstractions and not in the algorithms that construct them.In our search of a unified theme, we view a heap abstraction as consisting of two features: a heap model to represent the heap memory and a summarization technique for bounding the heap representation. We classify the models as storeless, store based, and hybrid. We describe various summarization techniques based on k-limiting, allocation sites, patterns, variables, other generic instrumentation predicates, and higher-order logics. This approach allows us to compare the insights of a large number of seemingly dissimilar heap abstractions and also paves way for creating new abstractions by mix-and-match of models and summarization techniques. Heap Analysis: MotivationHeap data is potentially unbounded and seemingly arbitrary. Although there is a plethora of literature on heap, the formulations and formalisms often seem dissimilar. This survey is a result of our quest for a unifying theme in the existing descriptions of heap. Why Heap?Unlike stack or static memory, heap memory allows on-demand memory allocation based on the statements in a program (and not just variable declarations). Thus it facilitates creation of flexible data structures which can outlive the procedures that create them and whose sizes can change during execution. With processors becoming faster and memories becoming larger as well as faster, the ability of creating large and flexible data structures increases. Thus the role of heap memory in user programs as well as design and implementation of programming languages becomes more significant. Why Heap Analysis? Why Heap Analysis?The increasing importance of the role of heap memory naturally leads to a myriad requirements of its analysis. Although heap data has been subjected to static as well as dynamic analyses, in this paper, we restrict ourselves to static analysis.Heap analysis, at a generic level, provides useful information about heap data, i.e. heap pointers or references. Additionally, it helps in discovering control flow through dynamic dispatch resolution. Specific applications that can benefit from heap analysis include program understanding, program refactoring, verification, debugging, enhancing security, improving performance, compile time garbage collection, inst...

show abstract

“…State Property (2): The action Π S t [s] on functions uses the mapping to monadic functions defined in Property (3):…”

Section: A1 Lemma 3 [ Galois Transformers ] (Section 84)mentioning

confidence: 99%

“…{x 1 → s 1 ..xn → sn} ← m 2 return m 2 ({x 1 → s 1 ..xn → sn}) ; f (x 1 )(s 1 ) ⊔ m 2 .. ⊔ m 2 f (xn)(sn)))({x → s})α m and γ m homomorphic and join functorality⊑ f (x)(s) α m • γ m extensive and left-unit of m Finally, Property (1) commutes, assuming that A → m 1 (B) − −−→ m 2 (B) is homomorphic: goal : ∀f s, F t [s][m 2 ](α m (f ))(x)(s) = α(F t [s][m 1 ](f ))(x)(s) α(F t [s][m 1 ](f ))(x)(s) = α m (λ({x 1 → s 1 ..xn → sn}). (y ← m 1 f (x) ; return m 1 (y 1 )(s 1 )) ⊔ m 1 ..⊔ m 1 (y ← m 1 f (x) ; return m 1 (yn)(sn)))({x → s}) definition of α and F t [s][m 1 ] = y ← m 2 α m (f )(x) ; return m 2 (y)(s) homomorphic on bind m 1 and return m F t [s][m 2 ](α m (f ))(x) definition of F t [s][m 2 ]Flow Sensitivity Property(2): The action Π F t [s] on functions uses the mapping to monadic functions defined in Property(3):Π F t [s] : (Σ(A) → Σ(B)) → Π F t [s](Σ)(A) → Π F t [s](Σ)(B) Π F t [s](f )(ς) := γ Σ↔γ (F t [s](α Σ↔γ (f )))To transport Galois connections, we assume a Galois connection Σ 1 (A) → Σ 1 (B) − −−A) → Σ 2 (B) and define α and γ as instantiations of α Σ and γ Σ :…”

mentioning

confidence: 99%

Galois transformers and modular abstract interpreters: reusable metatheory for program analysis

Darais

Might

Horn

2015

Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applicatio

View full text Add to dashboard Cite

The design and implementation of static analyzers has become increasingly systematic. Yet for a given language or analysis feature, it often requires tedious and error prone work to implement an analyzer and prove it sound. In short, static analysis features and their proofs of soundness do not compose well, causing a dearth of reuse in both implementation and metatheory.We solve the problem of systematically constructing static analyzers by introducing Galois transformers: monad transformers that transport Galois connection properties. In concert with a monadic interpreter, we define a library of monad transformers that implement building blocks for classic analysis parameters like context, path, and heap (in)sensitivity. Moreover, these can be composed together independent of the language being analyzed.Significantly, a Galois transformer can be proved sound once and for all, making it a reusable analysis component. As new analysis features and abstractions are developed and mixed in, soundness proofs need not be reconstructed, as the composition of a monad transformer stack is sound by virtue of its constituents. Galois transformers provide a viable foundation for reusable and composable metatheory for program analysis.Finally, these Galois transformers shift the level of abstraction in analysis design and implementation to a level where non-specialists have the ability to synthesize sound analyzers over a number of parameters.

show abstract

Analysis of pointers and structures

Cited by 116 publications

References 26 publications

On the verification of SCOOP programs

On the verification of SCOOP programs

Heap Abstractions for Static Analysis

Galois transformers and modular abstract interpreters: reusable metatheory for program analysis

Contact Info

Product

Resources

About