I-Corps: Automatically Localizing Functional Faults In Deployed Software Applications

点击翻译按钮获取中文摘要

Very few problems impact people more negatively than field failures, where deployed software behaves incorrectly. Just like distinct human anatomies would prevent medical professionals from quickly diagnosing diseases using symptoms, production fault localization requires a huge effort from software professionals, since each software application has its own unique structure and programmers must spend a lot of time to understand it even for smaller applications. Not only do field failures zap customer confidence in software applications, but also they cost dearly, sometimes in human lives, since software applications support all aspects of our lives. Despite hundreds of different approaches for fault localization, the problem of localizing production faults for field failures automatically is unsolved. A problem is that production faults are not known by definition when the application is deployed, therefore running existing test suites is not applicable. Only when field failures occur in a deployed application can programmers start analyzing the symptoms to determine what faults cause them. Time to fix is critical, since the applications' downtime often costs thousands of dollars per minute. Currently, there is no solution that can automatically localize functional production faults in deployed software applications with a high degree of precision using only symptoms of the field failures and input values and without deploying instrumented applications and without collecting any runtime data and without having any tests with oracles, without performing successful and failed runs, and without collecting large amounts of state information from field failures. This I-Corps team proposes a novel research program for Automatically Localizing Faults For Functional Field Failures in Applications (pronounced as al-five) that enables stakeholders to enter symptoms of a failure that occurs during deployment of a given application and the input and configuration parameter values, and ALF5 will return locations in the code that are likely to contain specific faults and it recommends modifications to the code at these locations that can fix these faults. Examples of symptoms of failures include but not limited to incorrect output values, program crashes and computations that take much more time that they are supposed to, possibly indicating infinite loops. The team plans to explore partnering with potential customers who can provide production worthy systems upon which to demonstrate the proposed innovation and can help the team scale up its innovation to commercial delivery. The most likely markets for the proposed innovation are: software systems developers, like IBM Global Services and Sapient and Accenture; business process outsourcing firms like Deloitte and CSC, that host complex applications on behalf of customers; and companies with complex in-production custom systems, e.g., insurance processing, transportation logistics.