/ PSWLAB Evidence-Based Analysis and Inferring Preconditions for Bug Detection By D. Brand, M. Buss, V. C. Sreedhar published in ICSM rd Oct, 2008 Hong,Shin Evidence-Based Analysis and Inferring Preconditions for Bug Detection

/ PSWLAB Contents Introduction Falsification Condition Assigning Evidence Interprocedural Evidence-Based Analysis Experience Conclusion Evidence-Based Analysis and Inferring Preconditions for Bug Detection 2

/ PSWLAB Introduction 1/2 Static analysis tools are promising for detecting program errors. In software developers perspective, it is important to address two problems for gaining wider acceptance of static analysis tools: –Minimizing false alarms –Minimizing program specification Therefore, it is important for tools to improve their accuracy in face of very little or even no user-provided specifications.  Tools should infer specification from the code. Evidence Based Analysis The tool reports a fault only if the tool can find evidence that the fault can be reached during execution that started with legal inputs Evidence-Based Analysis and Inferring Preconditions for Bug Detection 3

/ PSWLAB Introduction 2/2 int foo(int * x) { return *x ; } /* version 1 */ Evidence-Based Analysis and Inferring Preconditions for Bug Detection 4 We have no document for foo() and know nothing about its potential callers. Should we report that foo() is incorrect? - It may differ from project to project. Should we report that foo() version 2 is incorrect? - foo() version 2 has an evidence that x might be NULL. int foo(int * x) { if (x != NULL) bar() ; return *x ; } /* version 2*/

/ PSWLAB Falsification Condition 1/7 Software verification technique –Prove the absence of errors in a program with respect to a given specification of the program. Evidence-based analysis –Prove the presence of errors without requiring specification. –Extract specifications from a program code first and then verify the absence of errors in the program with the extracted specifications Evidence-Based Analysis and Inferring Preconditions for Bug Detection 5

/ PSWLAB Falsification Condition 2/7 Software verification A program is a set of global variables and procedures. A procedure is represented by a control flow graph(CFG). –Nodes represent program statements. –Edges represent flow of control. Edges have labels representing conditions that need to be satisfied in order for the edge to be traversed. A path in a CFG through a program is an alternating sequence of nodes and edges Evidence-Based Analysis and Inferring Preconditions for Bug Detection 6

/ PSWLAB Falsification Condition 3/7 A path P is assumed to have its pre-condition precondition ( P ) and its post-condition postcondition ( P ). The pre-condition is in terms of special symbols representing the initial values of variables, denoted by a vector x. The post- condition and all the expressions appearing along the path are in terms of program variables. We can replace values of program variables with their contents, which are symbolic expressions in terms of the initial values of x (by symbolic execution). As a result, each edge e has attached a predicate pred e, which is a boolean expression in terms of the initial values x Evidence-Based Analysis and Inferring Preconditions for Bug Detection 7

/ PSWLAB Falsification Condition 4/7 Verification condition The verification condition of a path P is valid if and only if for all initial values x the post-condition must be true whenever the precondition and all the predicates on the path are true Evidence-Based Analysis and Inferring Preconditions for Bug Detection 8 Falsification condition A valid falsification of a path implies the reachability of an error when the path is exercised with legal inputs. In verification condition, precondition ( P ) defines legal input of P. However, in falsification condition, valid input has to be accomplished without knowing its precondition.  Extract information from source codes.

/ PSWLAB Falsification Condition 5/7 The Information of pre-condition of a path is represented by associating evidence, evid e, with each edge e along the path. Each evidence evid e is one of three values: admissible, inadmissible, or asserted. In an effort to convict an error site, prosecution asserts an asserted evidence and then calls witnesses that are edges along particular path. In order to convict the asserted evidence, the prosecution must collect enough admissible evidences to imply the assertion Evidence-Based Analysis and Inferring Preconditions for Bug Detection 9

/ PSWLAB Falsification Condition 6/7 The falsification condition of a path P is satisfiable if and only if all the predicates along P are satisfiable Evidence-Based Analysis and Inferring Preconditions for Bug Detection 10 The falsification condition of a path P is valid if and only if it is satisfiable and all the admissible predicates imply all the asserted predicates. and 9 e 2 P. evid e = admissible

/ PSWLAB Falsification Condition 7/ Evidence-Based Analysis and Inferring Preconditions for Bug Detection 11 Example int foo(int * x) { if (x != NULL) bar() ; return *x ; } Path P For path P, 8 x{ x == NULL ! x == NULL} admissible part asserted part

/ PSWLAB Assigning Evidence 1/4 The idea is based on that it is unusual for programmers to intentionally write useless code. For each language construct, we assign evidence values to inform that the predicates related to the construct might be admissible evidences of legal input, or evidence of possible errors. –For example, for a if-statement, both then-predicate and else- predicate would be admissible evidences. –However, for a loop-statement, the edge for zero iteration might not be admissible evidence. However, the assignments should depend on coding standards of an individual project and human psychology Evidence-Based Analysis and Inferring Preconditions for Bug Detection 12

/ PSWLAB Assigning Evidence 2/4 Error node Error nodes are generated in the process of translating given source code into the control flow graph. We assign asserted evidence to the incoming edge of error node. By inserting an error nod, we can transform the reachability of the error by the falsification condition of the path to the error node. Error nodes for null pointer dereference, divide by zero, array out of bound can be automatically inserted Evidence-Based Analysis and Inferring Preconditions for Bug Detection 13

/ PSWLAB Assigning Evidence 3/4 If and switch statement The then-branch and else-branch of an if-statement should be assigned admissible evidence. (the same for the case-branches of a switch statement) For cascaded-if statement (and omitting default case for a switch statement) Evidence-Based Analysis and Inferring Preconditions for Bug Detection 14 int a[3] ; int is_i_out_of_range(unsigned i) { int r ; if (i == 0) r = 0 ; else if (i == 1) r = 1 ; else if (i == 2) r = 2 ; return a[i] ; } /* example 1 */ int a[3] ; int is_i_out_of_range(unsigned i) { int r ; if (i == 0) r = 0 ; else if (i == 1) r = 1 ; else if (i == 2) r = 2 ; return r ; } /* example 2 */ i != 0 && i != 1 && i != 2 ? uninitialized i != 0 && i != 1 && i != 2 admssible

/ PSWLAB Assigning Evidence 4/4 Loops It can be accomplished by assigning inadmissible evidence to the false- branch of the loop condition the very first time it is evaluated, while assigning admissible evidence thereafter. Example 1Example 2 For a if-statement inside a loop, we assign admissible evidence only if it does not relate with variables modified by the loop Evidence-Based Analysis and Inferring Preconditions for Bug Detection 15

/ PSWLAB Interprocedural Evidence-Based Analysis The purpose of interprocedural analysis is to propagate information calculated in the body of one procedure to those calling it. In the form of procedure summaries, information is propagated from callees to callers. A procedure summary is the generated preconditions (admissible evidences). For a procedural call, the caller first finds a procedure summary of the callee. Callers are then check to see if they pass illegal inputs to callee. If there is not enough evidence inside the caller to prove that the inputs are illegal, the caller gets another summary expressing its legal inputs Evidence-Based Analysis and Inferring Preconditions for Bug Detection 16

/ PSWLAB ev-0: edges leading to error nodes and all edges inside callees have asserted evidence; all other edges have inadmissible evidence ev-1: same as ev-0, except in the caller then-branches of if-statements have admissible evidence ev-2: same as ev-1, except in the caller else-branches of simple if-statements have admissible evidence ev-3: same as ev-2, except in the caller else-branches of cascaded if-statements have admissible evidence … ev-9: same as ev-8, except inside callees edges have admissible evidence Experience 1/2 The method has been implemented in an IBM internal tool called BEAM. The tool has flexibility of changing evidence settings. Moreover, it supports 10 levels of evidence settings. The number of error reported becomes tolerable even with the highest evidence setting for real users Evidence-Based Analysis and Inferring Preconditions for Bug Detection 17

/ PSWLAB Experience 2/2 A reported error found in firestorm mesg_initlog(tv, code, buf) contains the expression mesg_str[code] where the size of mesg_str is 6. However, mesg_initlog() does not contain enough evidence to report the possibility of code being out of range. Therefore, instead, a precondition is generated for the function mesg_initlog ; 0 <= code < 6. Then inside another function mesg(code, fmt, …) there is a call mesg_initlog(&tv, code, buf) ; In addition, there is a statement if (code > 6) code = 0 ;. The tool have enough admissible evidence to falsify the generated precondition of mesg_initlog(tv, code, buf) so that this cause the tool to report an index-out-of-range error Evidence-Based Analysis and Inferring Preconditions for Bug Detection 18

/ PSWLAB Conclusion This approach determine whether a program will fail in an intended invocation environment without requiring any preconditions defining the intended environment. This approach reduces the incidence of false positives by reporting only those errors that happen for legal inputs. General user acceptance of the tool is an indication that it leads to improved software quality Evidence-Based Analysis and Inferring Preconditions for Bug Detection 19

/ PSWLAB Reference [1]Evidence-Based Analysis and Inferring Preconditions for Bug Detection / D.Brand, M.Buss, V.C.Sreedhar / ICSM Evidence-Based Analysis and Inferring Preconditions for Bug Detection 20