Detecting Interprocedural Infeasible Paths Based on Unsatisfiable Path Constraint Patterns

Abstract

The static analysis plays an important role in many software engineering activities. However, the existence of infeasible paths, which causes lower program test coverage and several false positives in the results of the static analysis, has become one of the biggest challenges for the static analysis. In this paper, based on unsatisfiable path constraint patterns, we present a new approach to detect interprocedural infeasible paths. In our approach, we first discover nine unsatisfiable path constraint patterns by mining the common path constraint features of a large number of infeasible paths. Then, we detect the interprocedural infeasible paths; a detected path is deemed to be an interprocedural infeasible path if its simplified constraint conditions match one of the nine unsatisfiable path constraint patterns. To illustrate and verify the approach, an experimental study is performed on five open source C projects. The results show that compared with the existing approach, our approach requires less time on average and detects more interprocedural infeasible paths among the given paths. INDEX TERMS Static analysis, infeasible path, constraint pattern, interprocedural analysis.

Computing Maximum Fixed Point Solutions Over Feasible Paths in Data Flow Analyses

“…In general, presence of infeasible paths in programs is well known [29,30,12,31,32,33,34,35]. Hedley et al [30] presented a detailed analysis of the causes and effects of infeasible paths in programs.…”

Inter-Procedural Diagnosis Path Generation for Automatic Confirmation of Program Suspected Faults

“…The intraprocedural diagnosis path is generated first, then the interprocedural diagnosis path is generated according to the intra-procedural diagnosis path and the function call relationship. We use the unsatisfiable path constraint patterns to detect the infeasible paths during the intraprocedural and inter-procedural diagnosis path generation [29]. With the simplified CFG of each associated procedure and the sequence of function calls related to the procedure that the suspected fault is located in it, we backward traverse the simplified CFG from the suspected fault point or a call site.…”