1 / 20

Evidence-Based Analysis and Inferring Preconditions for Bug Detection

Evidence-Based Analysis and Inferring Preconditions for Bug Detection. By D. Brand, M. Buss, V. C. Sreedhar published in ICSM 2007 3 rd Oct, 2008 Hong,Shin. Contents. Introduction Falsification Condition Assigning Evidence Interprocedural Evidence-Based Analysis Experience Conclusion.

huy
Download Presentation

Evidence-Based Analysis and Inferring Preconditions for Bug Detection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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

  4. Introduction 2/2 int foo(int * x) { return *x ; } /* version 1 */ int foo(int * x) { if (x != NULL) bar() ; return *x ; } /* version 2*/ • 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. Evidence-Based Analysis and Inferring Preconditions for Bug Detection

  5. 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

  6. 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

  7. 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 prede, which is a boolean expression in terms of the initial values x. Evidence-Based Analysis and Inferring Preconditions for Bug Detection

  8. 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. • 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. Evidence-Based Analysis and Inferring Preconditions for Bug Detection

  9. Falsification Condition 5/7 • The Information of pre-condition of a path is represented by associating evidence, evide, with each edge e along the path. • Each evidence evide 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

  10. Falsification Condition 6/7 • The falsification condition of a path P is satisfiable if and only if all the predicates along P are satisfiable. • 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 9e2P . evide = admissible Evidence-Based Analysis and Inferring Preconditions for Bug Detection

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

  12. 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

  13. 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

  14. 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) 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 */ uninitialized i != 0 && i != 1 && i != 2 ? i != 0 && i != 1 && i != 2 admssible Evidence-Based Analysis and Inferring Preconditions for Bug Detection

  15. 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 1 Example 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

  16. 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

  17. 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. 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 Evidence-Based Analysis and Inferring Preconditions for Bug Detection

  18. Experience 2/2 A reported error found in firestorm-0.5.4 • 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

  19. 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

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

More Related