Abstract
TimSort is the main sorting algorithm provided by the Java standard library and many other programming frameworks. Our original goal was functional verification of TimSort with mechanical proofs. However, during our verification attempt we discovered a bug which causes the implementation to crash by an uncaught exception. In this paper, we identify conditions under which the bug occurs, and from this we derive a bug-free version that does not compromise performance. We formally specify the new version and verify termination and the absence of exceptions including the bug. This verification is carried out mechanically with KeY, a state-of-the-art interactive verification tool for Java. We provide a detailed description and analysis of the proofs. The complexity of the proofs required extensions and new capabilities in KeY, including symbolic state merging.
Highlights
Among the arguments that are routinely invoked against the usage of formal software verification one can find the following: it is expensive, it is not worthwhile, it is less effective than bug finding, it does not work for “real” software
Each class is equipped with an invariant that has to be re-established by each method upon termination. These formal specifications are expressed in the Java Modeling Language (JML) [14]
During our verification attempt we discovered that the fix to the bug mentioned above is not working [13] and that the “fixed” version crashes with an uncaught top-level exception on certain inputs
Summary
Among the arguments that are routinely invoked against the usage of formal software verification one can find the following: it is expensive, it is not worthwhile (compared to its cost), it is less effective than bug finding (e.g., by testing, static analysis, or model checking), it does not work for “real” software. Because of the complexity of the code under verification, it is essential to break down the problem into sub-tasks of manageable size. This is achieved with contract-based deductive verification [4], where the functionality and the side effects of each method are precisely specified with expressive first-order contracts. Each class is equipped with an invariant that has to be re-established by each method upon termination. These formal specifications are expressed in the Java Modeling Language (JML) [14]
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
