Jaechang Nam

Jaechang Nam, Ning Chen

During the life cycle of software development, developers have to fix different kinds of bugs reported by testers or end users. The efficiency and effectiveness of fixing bugs have a huge impact on the reliability of the software as well as the productivity of the development team. Software companies usually spend a large amount of money and human resources on the testing and bug fixing departments. As a result, a better and more reliable way to fix bugs is highly desired by them. In order to achieve such goal, in depth studies on the characteristics of bug fixes from well maintained, highly popular software projects are necessary. In this paper, we study the bug fixing histories extracted from the Eclipse project, a well maintained, highly popular open source project. After analyzing more than 36,000 bugs that belongs to three major kinds of exception types, we are able to reveal some common fix types that are frequently used to fix certain kinds of program exceptions. Our analysis shows that almost all of the exceptions that belong to a certain exception can be fixed by less than ten fix types. Our result implies that most of the bugs in software projects can be and should be fixed by only a few common fix patterns.

Yunseo Lee, John Youngeun Song, Dongsun Kim et al.

Recent technical breakthroughs in large language models (LLMs) have enabled them to fluently generate source code. Software developers often leverage both general-purpose and code-specialized LLMs to revise existing code or even generate a whole function from scratch. These capabilities are also beneficial in no-code or low-code contexts, in which one can write programs without a technical background. However, due to their internal design, LLMs are prone to generating hallucinations, which are incorrect, nonsensical, and not justifiable information but difficult to identify its presence. This problem also occurs when generating source code. Once hallucinated code is produced, it is often challenging for users to identify and fix it, especially when such hallucinations can be identified under specific execution paths. As a result, the hallucinated code may remain unnoticed within the codebase. This survey investigates recent studies and techniques relevant to hallucinations generated by CodeLLMs. We categorize the types of hallucinations in the code generated by CodeLLMs, review existing benchmarks and mitigation strategies, and identify open challenges. Based on these findings, this survey outlines further research directions in the detection and removal of hallucinations produced by CodeLLMs.

Jiho Shin, Reem Aleithan, Jaechang Nam et al.

Explaining the prediction results of software defect prediction models is a challenging while practical task, which can provide useful information for developers to understand and fix the predicted bugs. To address this issue, recently, Jiarpakdee et al. proposed to use {two state-of-the-art} model-agnostic techniques (i.e., LIME and BreakDown) to explain the prediction results of bug prediction models. Their experiments show these tools can generate promising results and the generated explanations can assist developers understand the prediction results. However, the fact that LIME and BreakDown were only examined on a single software defect prediction model setting calls into question about their consistency and reliability across software defect prediction models with various settings. In this paper, we set out to investigate the consistency and reliability of model-agnostic technique based explanation generation approaches (i.e., LIME and BreakDown) on software defect prediction models with different settings , e.g., different data sampling techniques, different machine learning classifiers, and different prediction scenarios. Specifically, we use both LIME and BreakDown to generate explanations for the same instance under software defect prediction models with different settings and then check the consistency of the generated explanations for the instance. We reused the same defect data from Jiarpakdee et al. in our experiments. The results show that both LIME and BreakDown generate inconsistent explanations under different software defect prediction settings for the same test instances, which makes them unreliable for explanation generation. Overall, with this study, we call for more research in explainable software defect prediction towards achieving consistent and reliable explanation generation.