Further Lessons from the JML Project

Leavens, Gary T.; Cok, David R.; Nilizadeh, Amirfarhad

doi:10.1007/978-3-031-08166-8_15

Cited by 2 publications

(3 citation statements)

References 99 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The Java Modeling Language (JML) (Leavens et al 2006(Leavens et al , 2008(Leavens et al , 2022) is a well-known Hoare-style formal behavioral interface specification language specifically designed for Java. Serving as a deductive specification language, JML describes the expected behavior of Java methods, classes, and interfaces using preconditions and postconditions.…”

Section: Java Modeling Languagementioning

confidence: 99%

“…JMLKelinci (A. Nilizadeh, Leavens, & Pȃsȃreanu 2021) uses a RAC tool (OpenJML (Cok 2010(Cok , 2011(Cok , 2021) with a CGF (Kelinci (Kersten et al 2017)) to provide valid inputs for Java programs. JMLKelinci obtains the benefits of using preconditions written in JML (Leavens et al 2006(Leavens et al , 2008(Leavens et al , 2022 to cover branches with only valid inputs to provide the opportunity of using postconditions for revealing potential semantic bugs. JMLKelinci only uses the first step of this paper's idea by using formal preconditions for generating valid inputs; the JM-LKelinci tool has not yet been adapted to investigate checking postconditions or to send feedback to the fuzzer regarding the presence of semantic bugs.…”

Section: Preliminary Studymentioning

confidence: 99%

“…Thus, the effectiveness of RAC for revealing bugs is dependent on the input test data. However, when using RAC together with a specification language, such as JML (Leavens et al 2006(Leavens et al , 2008(Leavens et al , 2022 or Eiffel (Meyer 1997), one does not provide the expected output for each input but instead a lightweight specification for each method, consisting of a precondition and a postcondition. A Precondition is an assertion that describes what input states are valid, and a postcondition describes the correct relation between input and output states.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Toward Using Fuzzers and Lightweight Specifications to Reveal Semantic Bugs.

Nilizadeh,

Leavens,

Cok

2024

JOT

View full text Add to dashboard Cite

Although fuzzers have been successful in revealing semantic bugs that lead to crashes, they do not reveal semantic bugs that do not lead to crashes. Furthermore, the inputs that lead to crashes may be invalid and invalid inputs do not reveal semantic bugs at all, since they are outside the program's intended input domain. On the other hand, runtime assertion checking (RAC) may be used for revealing semantic bugs, although it needs input test data that can trigger these bugs.In this idea paper, we propose the idea of combining different kinds of fuzzing tools and RAC in a complementary manner to leverage their benefits and overcome these problems, along with a preliminary study. That is, a fuzzing tool will generate an input test, and a RAC tool will make sure that the generated inputs are valid and check the results for semantic bugs.

show abstract

Section: Java Modeling Languagementioning

confidence: 99%

Section: Preliminary Studymentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Toward Using Fuzzers and Lightweight Specifications to Reveal Semantic Bugs.

Nilizadeh,

Leavens,

Cok

2024

JOT

View full text Add to dashboard Cite

show abstract

JMLKelinci+: Detecting Semantic Bugs and Covering Branches with Valid Inputs Using Coverage-guided Fuzzing and Runtime Assertion Checking

Nilizadeh,

Leavens,

Păsăreanu

et al. 2024

Form. Asp. Comput.

View full text Add to dashboard Cite

Testing to detect semantic bugs is essential, especially for critical systems. Coverage-guided fuzzing (CGF) and runtime assertion checking (RAC) are two well-known approaches for detecting semantic bugs. CGF aims to generate test inputs with high code coverage. However, while CGF tools can be equipped with sanitizers to detect a fixed set of semantic bugs, they can otherwise only detect bugs that lead to a crash. Thus, the first problem we address is how to help fuzzers detect previously unknown semantic bugs that do not lead to a crash. Moreover, a CGF tool may not necessarily cover all branches with valid inputs, although invalid inputs are useless for detecting semantic bugs. So, the second problem is how to guide a fuzzer to maximize coverage using only valid inputs. On the other hand, RAC monitors the expected behavior of a program dynamically and can only detect a semantic bug when a valid test input shows that the program does not satisfy its specification. Thus, the third problem is how to provide high-quality test inputs for a RAC that can trigger potential bugs. The combination of a CGF tool and RAC solves these problems and can cover branches with valid inputs and detect semantic bugs effectively. Our study uses RAC to guarantee that only valid inputs reach the program under test using the program’s specified preconditions and it also uses RAC to detect semantic bugs using specified postconditions. A prototype tool was developed for this study, named JMLKelinci+. Our results show that combining a CGF tool with RAC will lead to executing the program under test only with valid inputs and that this technique can effectively detect semantic bugs. Also, this idea improves the feedback given to a CGF tool, enabling it to cover all branches faster in programs with non-trivial preconditions.

show abstract

Further Lessons from the JML Project

Cited by 2 publications

References 99 publications

Toward Using Fuzzers and Lightweight Specifications to Reveal Semantic Bugs.

Toward Using Fuzzers and Lightweight Specifications to Reveal Semantic Bugs.

JMLKelinci+: Detecting Semantic Bugs and Covering Branches with Valid Inputs Using Coverage-guided Fuzzing and Runtime Assertion Checking

Contact Info

Product

Resources

About