Daniil Stepanov

dblp:249/2250 · DBLP profile ↗
← Back
2ranked-venue papers
2as first author
1since 2021 · last 2021
0000-0003-1719-0325ORCID · corroborated

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 2 · 2 first-author · 1 since 2021

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Debugging and program repair · 67% Program analysis · 33%

Topics — the 3 heaviest of 3, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Debugging and program repair › automated debugging
delta debugging
0.412019
ReduKtor: How We Stopped Worrying About Bugs in Kotlin Compiler · ASE 2019
Debugging and program repair
fault localization
0.412019
ReduKtor: How We Stopped Worrying About Bugs in Kotlin Compiler · ASE 2019
Program analysis › static analysis
program slicing
0.412019
ReduKtor: How We Stopped Worrying About Bugs in Kotlin Compiler · ASE 2019

Methods — techniques the papers use, named apart from their topics

program slicing · 0.4hierarchical delta debugging · 0.4
YearPublicationVenuePosition
2021 Type-Centric Kotlin Compiler Fuzzing: Preserving Test Program Correctness by Preserving Types
abstract
Kotlin is a relatively new programming language from JetBrains: its development started in 2010 with release 1.0 done in early 2016. The Kotlin compiler, while slowly and steadily becoming more and more mature, still crashes from time to time on the more tricky input programs, not least because of the complexity of its features and their interactions. This makes it a great target for fuzzing, even the basic forms of which can find a significant number of Kotlin compiler crashes. There is a problem with fuzzing, however, closely related to the cause of the crashes: generating a random, non-trivial and semantically valid Kotlin program is hard. In this paper, we talk abouttype-centriccompilerfuzzingin the form oftype-centricenumeration, an approach inspired by skeletal program enumeration [1] and based on a combination of generative and mutation-based fuzzing, which solves this problem by focusing on programtypes. After creating the skeleton program, we fill the typed holes with fragments of suitable type, created via generation and enhanced by semantic-aware mutation. We implemented this approach in our Kotlin compiler fuzzing framework called Backend Bug Finder (BBF) and did an extensive evaluation, not only testing the real-world feasibility of our approach, but also comparing it to other compiler fuzzing techniques. The results show our approach to be significantly better compared to other fuzzing approaches at generating semantically valid Kotlin programs, while creating more interesting crash-inducing inputs at the same time. We managed to find more than 50 previously unknown compiler crashes, of which 18 were considered important after their triage by the compiler team.
Daniil Stepanov, Marat Kh. Akhin, Mikhail A. Belyaev
ICST1
2019 ReduKtor: How We Stopped Worrying About Bugs in Kotlin Compiler
abstract
Bug localization is well-known to be a difficult problem in software engineering, and specifically in compiler development, where it is beneficial to reduce the input program to a minimal reproducing example; this technique is more commonly known as delta debugging. What additionally contributes to the problem is that every new programming language has its own unique quirks and foibles, making it near impossible to reuse existing tools and approaches with full efficiency. In this experience paper we tackle the delta debugging problem w.r.t. Kotlin, a relatively new programming language from JetBrains. Our approach is based on a novel combination of program slicing, hierarchical delta debugging and Kotlin-specific transformations, which are synergistic to each other. We implemented it in a prototype called ReduKtor and did extensive evaluation on both synthetic and real Kotlin programs; we also compared its performance with classic delta debugging techniques. The evaluation results support the practical usability of our approach to Kotlin delta debugging and also shows the importance of using both language-agnostic and language-specific techniques to achieve best reduction efficiency and performance.
Daniil Stepanov, Marat Kh. Akhin, Mikhail A. Belyaev
ASE1