107,969 research outputs found
Directed Incremental Symbolic Execution
The last few years have seen a resurgence of interest in the use of symbolic execution -- a program analysis technique developed more than three decades ago to analyze program execution paths. Scaling symbolic execution and other path-sensitive analysis techniques to large systems remains challenging despite recent algorithmic and technological advances. An alternative to solving the problem of scalability is to reduce the scope of the analysis. One approach that is widely studied in the context of regression analysis is to analyze the differences between two related program versions. While such an approach is intuitive in theory, finding efficient and precise ways to identify program differences, and characterize their effects on how the program executes has proved challenging in practice. In this paper, we present Directed Incremental Symbolic Execution (DiSE), a novel technique for detecting and characterizing the effects of program changes. The novelty of DiSE is to combine the efficiencies of static analysis techniques to compute program difference information with the precision of symbolic execution to explore program execution paths and generate path conditions affected by the differences. DiSE is a complementary technique to other reduction or bounding techniques developed to improve symbolic execution. Furthermore, DiSE does not require analysis results to be carried forward as the software evolves -- only the source code for two related program versions is required. A case-study of our implementation of DiSE illustrates its effectiveness at detecting and characterizing the effects of program changes
Directed symbolic execution
In this paper, we study the problem of automatically finding program
executions that reach a particular target line. This problem arises in
many debugging scenarios, e.g., a developer might learn that a failure
is possible on a particular line but might not know exactly how to
reproduce the failure or even whether it is reproducible. This can
happen particularly often for bug reports from static analysis tools,
which can produce false positives. We propose two new directed symbolic
execution strategies that aim to solve this problem: shortest-distance
symbolic execution (SDSE) uses a distance metric in an interprocedural
control flow graph to guide symbolic execution toward a particular
target; and call-chain-backward symbolic execution (CCBSE) iteratively
runs forward symbolic execution, starting in the function containing the
target line, and then jumping backward up the call chain until it finds
a feasible path from the start of the program. We also propose Mix-
CCBSE, a strategy in which CCBSE is composed with another search
strategy to yield a hybrid that is more powerful than either strategy
alone. We compare SDSE, CCBSE, and Mix-CCBSE with several existing
strategies from the literature. We find that, while SDSE performs
extremely well in many cases, it sometimes fails badly. However, by
mixing CCBSE with KLEE's search strategy, we obtain a strategy that has
the best overall performance across the strategies we studied
Improving Function Coverage with Munch: A Hybrid Fuzzing and Directed Symbolic Execution Approach
Fuzzing and symbolic execution are popular techniques for finding
vulnerabilities and generating test-cases for programs. Fuzzing, a blackbox
method that mutates seed input values, is generally incapable of generating
diverse inputs that exercise all paths in the program. Due to the
path-explosion problem and dependence on SMT solvers, symbolic execution may
also not achieve high path coverage. A hybrid technique involving fuzzing and
symbolic execution may achieve better function coverage than fuzzing or
symbolic execution alone. In this paper, we present Munch, an open source
framework implementing two hybrid techniques based on fuzzing and symbolic
execution. We empirically show using nine large open-source programs that
overall, Munch achieves higher (in-depth) function coverage than symbolic
execution or fuzzing alone. Using metrics based on total analyses time and
number of queries issued to the SMT solver, we also show that Munch is more
efficient at achieving better function coverage.Comment: To appear at 33rd ACM/SIGAPP Symposium On Applied Computing (SAC). To
be held from 9th to 13th April, 201
The Progress, Challenges, and Perspectives of Directed Greybox Fuzzing
Most greybox fuzzing tools are coverage-guided as code coverage is strongly
correlated with bug coverage. However, since most covered codes may not contain
bugs, blindly extending code coverage is less efficient, especially for corner
cases. Unlike coverage-guided greybox fuzzers who extend code coverage in an
undirected manner, a directed greybox fuzzer spends most of its time allocation
on reaching specific targets (e.g., the bug-prone zone) without wasting
resources stressing unrelated parts. Thus, directed greybox fuzzing (DGF) is
particularly suitable for scenarios such as patch testing, bug reproduction,
and specialist bug hunting. This paper studies DGF from a broader view, which
takes into account not only the location-directed type that targets specific
code parts, but also the behaviour-directed type that aims to expose abnormal
program behaviours. Herein, the first in-depth study of DGF is made based on
the investigation of 32 state-of-the-art fuzzers (78% were published after
2019) that are closely related to DGF. A thorough assessment of the collected
tools is conducted so as to systemise recent progress in this field. Finally,
it summarises the challenges and provides perspectives for future research.Comment: 16 pages, 4 figure
SmartUnit: Empirical Evaluations for Automated Unit Testing of Embedded Software in Industry
In this paper, we aim at the automated unit coverage-based testing for
embedded software. To achieve the goal, by analyzing the industrial
requirements and our previous work on automated unit testing tool CAUT, we
rebuild a new tool, SmartUnit, to solve the engineering requirements that take
place in our partner companies. SmartUnit is a dynamic symbolic execution
implementation, which supports statement, branch, boundary value and MC/DC
coverage. SmartUnit has been used to test more than one million lines of code
in real projects. For confidentiality motives, we select three in-house real
projects for the empirical evaluations. We also carry out our evaluations on
two open source database projects, SQLite and PostgreSQL, to test the
scalability of our tool since the scale of the embedded software project is
mostly not large, 5K-50K lines of code on average. From our experimental
results, in general, more than 90% of functions in commercial embedded software
achieve 100% statement, branch, MC/DC coverage, more than 80% of functions in
SQLite achieve 100% MC/DC coverage, and more than 60% of functions in
PostgreSQL achieve 100% MC/DC coverage. Moreover, SmartUnit is able to find the
runtime exceptions at the unit testing level. We also have reported exceptions
like array index out of bounds and divided-by-zero in SQLite. Furthermore, we
analyze the reasons of low coverage in automated unit testing in our setting
and give a survey on the situation of manual unit testing with respect to
automated unit testing in industry.Comment: In Proceedings of 40th International Conference on Software
Engineering: Software Engineering in Practice Track, Gothenburg, Sweden, May
27-June 3, 2018 (ICSE-SEIP '18), 10 page
- …