Open research topics

Under my supervision, you can do cool research in software technology, here are our current hot topics.

Are you a KTH student? See Master's thesis / Bachelor's thesis guidelines and contact me by email

Are you a brilliant international student? Contact me by email

Category Program Repair
     Machine Learning for Program Repair
          Generating Equivalent Patches with Neural Networks
          Automatic Repair with Large Models on Code
          Neural Repair of Compiler Warnings
          Conversational Program Repair Bots
     Code Analysis for program repair
          Automatic Repair of Breaking Dependency Updates
          Automatic Program Repair of Code4Bench
          Explainable repair templates for Astor
          Automated Program Repair for Smart Contracts
Category Program Hardening
     Chaos Engineering
          Do Applications Overreact to EAGAIN Errors?
          Automatic USDT Observability Probe Injection for Java Applications
     Software Testing
          On-chain code coverage
          Collection and Analysis of Code Coverage in Production
          Automatic Identification of Pseudo-tested Conditions
          Test Generation for Ethereum Clients Using Production Data
Category Software Supply Chain & Crypto
     Software Supply Chain
          Maven builds over IPFS
          Dynamic Software Integrity Verification
          Embedding the software supply chain at runtime with Java classloaders
          Behavioral Hardening for Blockchain Nodes
     Smart Contracts
          Automatic Exploit Synthesis for Smart Contracts
          Decompilation for Solidity and EVM Bytecode
          Automated Program Repair for Smart Contracts

Category Program Repair

Machine Learning for Program Repair

Generating Equivalent Patches with Neural Networks

Description: Recently, neural networks (NN) have been trained on source code, with different purposes such as code completion and automated program repair (APR). In the latter case, an NN-based APR receives as input a buggy code and generates patched code. In this thesis, you will study another use case for neural networks: generation of equivalent patches [1,2], that is, generated code that is semantically equivalent but syntactically different to the patch given as input, using self-supervision [3] In the context of APR, generating a set of equivalent patches will help APR systems generate a bunch of diverse equivalent patches, and consequently, will let the developer choose the one she considers most appropriate to be integrated into her codebase.

Automatic Repair with Large Models on Code

Description: Recently, very large language models have been trained on code (OpenAI Codex, Github Copilot). There are preliminary results suggesting that they are useful for program repair. In this thesis, you will make an empirical investigation on using large language models for program repair with strong baselines and state of the art datasets.

Neural Repair of Compiler Warnings

Description: It is a best practice to activate all warnings in a compiler. However, much work is needed to remediate the all. You will research in the area of machine learning for repairing compiler warnings. You will devise, implement and evaluate an approach based on sequence-to-sequence learning. The considered compilers are open and could be for example rust, go, clang, etc.

Conversational Program Repair Bots

Description: Repairnator is a program repair bot [1,2]. In order to work effectively with developers, development bots must be able to interact with the developers. We imagine conversational systems for pull request explanation: developers would be able to ask questions about the pull request, and the bot would answer to those questions [3]. Such a system can be data-driven, based on the analysis of the millions of similar conversations that have happened in open-source repositories. The system could use a chatbot library such as Rasa [4].

Code Analysis for program repair

Automatic Repair of Breaking Dependency Updates

Description: This work aims at automatically proposing patches for breaking updates of software libraries. It is a best practice to keep all software dependencies to use the latest version. However, some dependency versions are not compatible with the previous version. In this case, automated dependency management (eg with DependaBot or Renovate) still involves some heavy manual work in order to adapt the code to the new version of the library. The student will design, implement and evaluate novel program analysis and program synthesis techniques to automatically repair breaking updates.

Automatic Program Repair of Code4Bench

Description: The student will design design and perform a large scale experiment of program repair on the Code4Bench benchmark [1], with quantitative and qualitative analysis [2].

Explainable repair templates for Astor

Supervisor: Martin Monperrus (KTH Royal Institute of Technology), Matias Martinez (University of Valenciennes)

Description: In practice, template-based repair is promising, because they are very easy to explain to the developer and they also provide reduced overfitting. The student will design and implement a full-fledged template based system for Astor, based on the latest literature on repair templates. A large scale evaluation will be done on the novel repair benchmarks Bugs.jar and BEARS. we can play with the vocabulary to have pure language based templates and project-specific ones

Automated Program Repair for Smart Contracts

Description: Smart contracts are software, and hence, cannot be perfect. Smart contracts suffer from bugs, some of which putting high financial stakes at risk. There is a new line of research on automated patching of smart contract. You will devise, perform and analyze a comparative experiment to identify the successes, challenges and limitations of automated program repair for smart contracts.

Category Program Hardening

Chaos Engineering

Do Applications Overreact to EAGAIN Errors?

Description: EAGAIN is an error code that is predefined in a Linux kernel. Usually, if a system call invocation returns an error code EAGAIN, it means that the resource requested by an application is temporarily unavailable [1]. According to the error code's literal meaning, the application should try it 'again' later. This thesis project will explore to what extent software applications are overreacting to EAGAIN errors such as crashing directly [2] instead of a retry. For those overreacting applications, the student will apply self-healing techniques such as failure-oblivious computing [3] to investigate if the resilience of the application is improved.

Automatic USDT Observability Probe Injection for Java Applications

Description: In software debugging or software performance analysis, it is essential to have sufficient observability of the target software system [1]. One of the most popular techniques to improve observability is USDT (Userland Statically Defined Tracing) [2]. In the world of Java, such techniques are only applied to the JVM rather than to Java applications [3]. However, it is promising to add USDT probes directly in a Java application so that more application-specific metrics can be collected with negligible overhead. The thesis project will explore how to use Spoon [4] to automatically generate USDT probes for key events in a Java application.

Software Testing

On-chain code coverage

Programs executed on the Ethereum blockchain are defined through smart contracts. Solidity is the de-facto programming language used to implement smart contracts. Since much is at stake, good test coverage is essential for Solidity programs [1]. Coverage in production gives additional information about field usage [2], and the blockchain is a fully reproducible production workload. You will design and perform experiments to study production coverage in the context of smart contracts specified in Solidity.

solidity-coverage: https://github.com/sc-forks/solidity-coverage
Wang, Qianqian, Yuriy Brun, and Alessandro Orso. "Behavioral execution comparison: Are tests representative of field behavior?." 2017 IEEE International Conference on Software Testing, Verification and Validation (ICST). IEEE, 2017.

Collection and Analysis of Code Coverage in Production

Supervisors: Martin Monperrus (KTH)

Description: Code coverage usually relates to test code. Production code coverage is the coverage over real interactions made by users in production. Obtaining and analysing production code coverage enables to identify useless code as well as relevant test data and values. It enables testers and developers to better align the test intentions with what matters for users. The student will compare and analyze techniques for automatically collecting code coverage in production for Java software.

Automatic Identification of Pseudo-tested Conditions

Supervisors: Benoit Baudry, Martin Monperrus (KTH)

Description: One of the problems with coverage is that it does not detect unspecified code [1]. There is the same problem with conditions, some conditions are well covered according to edge coverage yet the code can actually take any branch without failing. The student will design, implement and evaluate a novel technique for automatically identifying pseudo-tested conditions in Java software.

Test Generation for Ethereum Clients Using Production Data

Description: Unit testing is one of the essential ways to improve the quality of software It is also helpful for correctness checking when there are different implementations based on the same software specification. Let us take Ethereum clients as an example, there are thousands of common tests [1] provided for all the Ethereum client projects. Though these tests have already cover various cases, there are corner cases in production that are missing in the test suite [2]. In this thesis project, you will design, implement and evaluate a prototype that collects production data and generate new valuable test cases for Ethereum clients.

Category Software Supply Chain & Crypto

See our previous work: Chaos Engineering of Ethereum Blockchain Clients The Multi-Billion Dollar Software Supply Chain of Ethereum

Software Supply Chain

Maven builds over IPFS

Description: Build with software integrity is an essential property for secure software supply chains [1]. One solution for this is to declare dependencies by immutable content and not by mutable URLs. The Interplanetary File System is a state-of-the-art solution in that space. You will design, implement and evaluate the first prototype ever of Maven builds over IPFS.

Dynamic Software Integrity Verification

Description: In the life cycle of a software application, the final step is to ship binaries to the production environment, and to execute them. In the simplest case, the production application is one single binary file. While this simple case was the norm three decades ago, it does not fit the reality today. In modern software stacks, a software application executing in production is the result of an assembly of many different files. This poses a major problem: the stakeholders of the software application have virtually no way to state what code is actually being executed in production. This is known as the “integrity checking problem” [1]. You will design, implement and evaluate a system such that software applications can tell at runtime their bill of materials.

Reflection as a mechanism for software integrity verification

Embedding the software supply chain at runtime with Java classloaders

Description: In Java, class loading refers to retrieving the binary form of a class or interface and constructing, from that binary form, a class object to represent the class or interface [1]. Today, different subclasses of the `ClassLoader` may implement different loading policies [2]. For example, a class loader may cache the binary representation of a class, prefetch it based on expected usage, or load a group of related classes together. These activities may not be completely transparent to a running application. In this context, determining the third-party suppliers of classes loaded at runtime allows for controlling and hardening the software supply chain of third-party components used during program execution. Monitoring the origins of the “actually” executed code is a critical task for building more reliable and secure systems. The student will design and implement a novel software tool to build a representation of the software supply chain at runtime.

Behavioral Hardening for Blockchain Nodes

Description: An important concept in software security is to protect resources with whitelists. It has been implemented at different levels of the software stack (kernel, virtual machines, application frameworks). In Bitcoin Core, white lists of system calls can be used and enforced via Linux SecComp [1]. From a research perspective, the hard problem is to infer the whitelist of accessible resources via behavioral analysis [2,3]. You will design and perform an experiment to compare different behavior inference techniques for Bitcoin-Core.

Smart Contracts

Automatic Exploit Synthesis for Smart Contracts

Smart contracts typically hold large stakes and consequently, they are under constant attack by malicious actors. As counter-measure, engineering smart contracts involves auditing and formal verification [1]. Another option is automatic exploit synthesis [2] In this thesis, you will evaluate the state of the art of exploit synthesis for smart contracts. You will then design, implement and evaluate a better system that improves upon the state of the art.

Decompilation for Solidity and EVM Bytecode

A decompiler takes compiled binary code and produces textual source code. Decompilation is an essential step for program comprehension, security analyses, etc. In this thesis, you will survey the state of the art of decompilation for Solidity. You will then design, implement and evaluate a better decompiler that improves upon the state of the art.