<> "The repository administrator has not yet configured an RDF license."^^ . <> . . "Automated Fault Localization in Large Java Applications"^^ . "Modern software systems evolve steadily. Software developers change the software codebase every day to add new features, to improve the performance, or to fix bugs.\r\nDespite extensive testing and code inspection processes before releasing a new software version, the chance of introducing new bugs is still high. A code that\r\nworked yesterday may not work today, or it can show a degraded performance causing software regression. The laws of software evolution state that the\r\ncomplexity increases as software evolves. Such increasing complexity makes software maintenance harder and more costly. In a typical software organization, the cost of\r\ndebugging, testing, and verification can easily range from 50% to 75% of the total development costs.\r\nGiven that human resources are the main cost factor in the software maintenance and the software codebase evolves continuously, this dissertation tries to answer the\r\nfollowing question: How can we help developers to localize the software defects more effectively during software development? We answer this question in three aspects.\r\nFirst, we propose an approach to localize failure-inducing changes for crashing bugs. Assume the source code of a buggy version, a failing test, the stack trace of the\r\ncrashing site, and a previous correct version of the application. We leverage program\r\nanalysis to contrast the behavior of the two software versions under the failing test.\r\nThe difference set is the code statements which contribute to the failure site with a high probability.\r\nSecond, we extend the version comparison technique to detect the leak-inducing defects caused by software changes. Assume two versions of a software codebase (one previous non-leaky and the current leaky version) and the existing test suite of the application. First, we compare the memory footprint of the code locations between two versions. Then, we use a confidence score to rank the suspicious code statements,\r\ni.e., those statements which can be the potential root causes of memory leaks. The higher the score, the more likely the code statement is a potential leak.\r\nThird, our observation on the related work about debugging and fault localization\r\nreveals that there is no empirical study which characterizes the properties of the leak-\r\ninducing defects and their repairs. Understanding the characteristics of the real defects\r\ncaused by resource and memory leaks can help both researchers and practitioners to improve the current techniques for leak detection and repair. To fill this gap, we conduct an empirical study on 491 reported resource and memory leak defects from 15 large Java applications. We use our findings to draw implications for leak avoidance,\r\ndetection, localization, and repair."^^ . "2019" . . . . . . . "Mohammadreza"^^ . "Ghanavati"^^ . "Mohammadreza Ghanavati"^^ . . . . . . "Automated Fault Localization in Large Java Applications (Other)"^^ . . . . . . "indexcodes.txt"^^ . . . "Automated Fault Localization in Large Java Applications (PDF)"^^ . . . "Dissertation_printed_version.pdf"^^ . . "HTML Summary of #26883 \n\nAutomated Fault Localization in Large Java Applications\n\n" . "text/html" . . . "004 Informatik"@de . "004 Data processing Computer science"@en . .