Aliases in a bug finding tool Benjamin Chelf Seth Hallem June 5 th, 2002

Overview Observation Bug-finding tools can be sound or unsound What distinguishes the results between them? Goal Evaluate varying levels of precision and soundness of how they handle aliases. Hypothesis Sound analysis is not necessary to detect of the types of bugs currently found by state of the art tools.

Alias analysis in Metal No alias analysis in Metal What must be done to add it? When transitioning a variable to a new state, must transition anything that may alias it. Alias analysis must provide the potential aliases given a program point and context. Caveat: When transitioning aliases, Metal must also insert identity transition edges.

Target Alias Analyses Sound analyses from the literature: Steensgard, CLA, Wilson/Lam, Instantiation Constraints, One-Level Flow (Das) Unsound Analyses no analysis (Metal as is) non-conservative single-level/double-level

Non-conservative analysis Reverse standard assumptions Conservative: unless we can guarantee that two pointers are not aliased, they could be aliased Non-conservative: assume pointers are not aliased and add aliasing relationships that we can identify easily One-level: p = q  p, q are aliased assume all pointers are one-level Two-level: p = q  p, q, *p, *q are aliased assume all pointers are at most two-level

One-level Aliasing: Example Tracked aliasing: int main (void) { int *p, *q; p = q; // p and q are aliased. free (p); // p and q are both freed. } Missed aliasing: caught with two-level int main (void) { int **p, **q; p = q; // p and q are aliased. free (*p); // *p is freed, *q is not. }

One-level Aliasing: Example Tracked aliasing: int main (void) { int *p, *q; p = q; // p and q are aliased. free (p); // p and q are both freed. } punk q

One-level Aliasing: Example Tracked aliasing: punk q int main (void) { int *p, *q; p = q; // p and q are aliased. free (p); // p and q are both freed. }

One-level Aliasing: Example Tracked aliasing: pfreed q int main (void) { int *p, *q; p = q; // p and q are aliased. free (p); // p and q are both freed. }

One level algorithm: basics Initially, assign each program object (typed expression) a “fresh” alias node node holds state attached to that object assignment: left-hand side inherits alias node from the right-hand side function call: formals = actuals save alias set at call, restore at return track struct fields, pointer arithmetic

Optimizations Kill sets Flow insensitively track second-level assignments. Track another level Alias relationships can pass up. Where is the 90% boundary?

Evaluation of analysis Who and what to check Buggy, real systems code (varying sizes) Null pointers, free errors, lock and unlock, etc. Metrics Running time of analysis and extensions # of bugs / # of false positives Traditional alias analysis metrics Reasons for imprecision Want to know why we have a false positive/negative

Research costs Difficult parts Implementation of analyses Bug finding interface Error report inspection (wading through FPs) Good sourceof future research Categorize FPs for simple elimination

Related work Bug finding Metal RHS Heine / Lam Alias analyses CLA (Andersen’s) Steensgard Instantiation Constraints Wilson / Lam One level flow (Das)