arXiv subjects

Rodrigo Bonifacio

Publications and source records attributed to Rodrigo Bonifacio.

3 recordsLinked to original sources

arXiv2026

Integrating Crash Report Mining and LLMs for Bug Localization and Repair: An Industrial Report

Analyzing crash-report bugs in large-scale industrial software systems requires substantial maintenance effort, particularly in production environments where developers must handle large volumes of crash reports and source code artifacts to localize and fix their root causes. While recent studies have shown that Large Language Models (LLMs) can assist with maintenance tasks, little is known about their effectiveness in supporting developers in analyzing crash-report bugs and repairing bugs associated with groups of crash reports in industrial settings. To address this gap, we investigate whether integrating crash report mining techniques---specifically stack trace clustering and suspicious file and method ranking---with LLMs can support crash localization and repair in production environments. We conduct a retrospective evaluation of five LLMs under four prompt configurations. After that, we chose the best model to run on 38 crash bugs collected from two large Java enterprise systems. We further analyze the structural characteristics and explanatory patterns of LLM-generated responses and assess localization and repair effectiveness through manual validation. Our results show that the best-performing configuration localizes up to 71% and correctly repairs 52% of crash bugs on the full dataset. These findings provide empirical evidence that combining crash report mining with LLM-based repair can effectively support debugging activities in industrial maintenance workflows.

cs.SE↗

arXiv2025

Mitigating Configuration Differences Between Development and Production Environments: A Catalog of Strategies

Context: The Configuration Management of the development and production environments is an important aspect of IT operations. However, managing the configuration differences between these two environments can be challenging, leading to inconsistent behavior, unexpected errors, and increased downtime. Objective: In this study, we sought to investigate the strategies software companies employ to mitigate the configuration differences between the development and production environments. Our goal is to provide a comprehensive understanding of these strategies used to contribute to reducing the risk of configuration-related issues. Method: To achieve this goal, we interviewed 17 participants and leveraged the Thematic Analysis methodology to analyze the interview data. These participants shed some light on the current practices, processes, challenges, or issues they have encountered. Results: Based on the interviews, we systematically formulated and structured a catalog of eight strategies that explain how software producing companies mitigate these configuration differences. These strategies vary from 1) creating detailed configuration management plans, 2) using automation tools, and 3) developing processes to test and validate changes through containers and virtualization technologies. Conclusion: By implementing these strategies, companies can improve their ability to respond quickly and effectively to changes in the production environment. In addition, they can also ensure compliance with industry standards and regulations.

cs.SE↗

arXiv2021

Dealing with Variability in API Misuse Specification

APIs are the primary mechanism for developers to gain access to externally defined services and tools. However, previous research has revealed API misuses that violate the contract of APIs to be prevalent. Such misuses can have harmful consequences, especially in the context of cryptographic libraries. Various API misuse detectors have been proposed to address this issue including CogniCrypt, one of the most versatile of such detectors and that uses a language CrySL to specify cryptographic API usage contracts. Nonetheless, existing approaches to detect API misuse had not been designed for systematic reuse, ignoring the fact that different versions of a library, different versions of a platform, and different recommendations or guidelines might introduce variability in the correct usage of an API. Yet, little is known about how such variability impacts the specification of the correct API usage. This paper investigates this question by analyzing the impact of various sources of variability on widely used Java cryptographic libraries including JCA, Bouncy Castle, and Google Tink. The results of our investigation show that sources of variability like new versions of the API and security standards significantly impact the specifications. We then use the insights gained from our investigation to motivate an extension to the CrySL language named MetaCrySL, which builds on meta programming concepts. We evaluate MetaCrySL by specifying usage rules for a family of Android versions and illustrate that MetaCrySL can model all forms of variability we identified and drastically reduce the size of a family of specifications for the correct usage of cryptographic APIs

cs.CR↗