Results 1 - 10
of
27
New frontiers of reverse engineering
- in: 2007 Future of Software Engineering, IEEE Computer Society
, 2007
"... interests include software maintenance and reverse engineering, service oriented software engineering, and experimental software engineering. He has co-authored more than 100 papers published in international journals and referred conferences and workshops. He was an associate editor of IEEE Transac ..."
Abstract
-
Cited by 36 (1 self)
- Add to MetaCart
(Show Context)
interests include software maintenance and reverse engineering, service oriented software engineering, and experimental software engineering. He has co-authored more than 100 papers published in international journals and referred conferences and workshops. He was an associate editor of IEEE Transactions on Software Engineering and he currently serves on the Editorial Board of the Journal of Software Maintenance and Evolution. He is a member of
Discovering faults in idiom-based exception handling.
- In Proceedings of the 28th International Conference on Software Engineering, ICSE ’06,
, 2006
"... ABSTRACT In this paper, we analyse the exception handling mechanism of a state-of-the-art industrial embedded software system. Like many systems implemented in classic programming languages, our subject system uses the popular return-code idiom for dealing with exceptions. Our goal is to evaluate t ..."
Abstract
-
Cited by 34 (1 self)
- Add to MetaCart
(Show Context)
ABSTRACT In this paper, we analyse the exception handling mechanism of a state-of-the-art industrial embedded software system. Like many systems implemented in classic programming languages, our subject system uses the popular return-code idiom for dealing with exceptions. Our goal is to evaluate the fault-proneness of this idiom, and we therefore present a characterisation of the idiom, a fault model accompanied by an analysis tool, and empirical data. Our findings show that the idiom is indeed fault prone, but that a simple solution can lead to significant improvements.
2002/21 Damaged Durable Goods Jong-Hee Hahn 2002/20 Unemployment Insurance under Moral Hazard and Limited Commitment: Public vs Private Provision Jonathan P Thomas and Tim Worrall 2002/19 The Water Poverty Index: an International Comparison Peter Lawrence
- In Rent-Seeking Contests With Entry Costs Richard Cornes and Roger Hartley 2002/10 Advantageous or Disadvantageous Semi-collusion Arijit Mukherjee 2002/09 Licensing in a Vertically Separated Industry Arijit Mukherjee 2002/08 U-shaped Paths of Consumption
, 2007
"... Although it is common in large Java programs to rethrow exceptions, existing exception-flow analyses find only single exceptionflow links, thus are unable to identify multiple-link exception propagation paths. This paper presents a new static analysis that, when combined with previous exception-flow ..."
Abstract
-
Cited by 23 (0 self)
- Add to MetaCart
(Show Context)
Although it is common in large Java programs to rethrow exceptions, existing exception-flow analyses find only single exceptionflow links, thus are unable to identify multiple-link exception propagation paths. This paper presents a new static analysis that, when combined with previous exception-flow analyses, computes chains of semantically-related exception-flow links, and thus reports entire exception propagation paths, instead of just discrete segments of them. These chains can be used 1) to show the error handling architecture of a system, 2) to assess the vulnerability of a single component and the whole system, 3) to support better testing of error recovery code, and 4) to facilitate the tracing of the root cause of a logged problem. Empirical findings and a case history for Tomcat show that a significant portion of the chains found in our benchmarks span multiple components, and thus are hard to find manually. 1
Exception analysis and points-to analysis: Better together
- ISSTA ’09: Proceedings of the 2009 International Symposium on Software Testing and Analysis
, 2009
"... Exception analysis and points-to analysis are typically done in complete separation. Past algorithms for precise exception analysis (e.g., pairing throw clauses with catch statements) use precomputed points-to information. Past points-to analyses either unsoundly ignore exceptions, or conservatively ..."
Abstract
-
Cited by 16 (4 self)
- Add to MetaCart
(Show Context)
Exception analysis and points-to analysis are typically done in complete separation. Past algorithms for precise exception analysis (e.g., pairing throw clauses with catch statements) use precomputed points-to information. Past points-to analyses either unsoundly ignore exceptions, or conservatively compute a crude approximation of exception throwing (e.g., considering an exception throw as an assignment to a global variable, accessible from any catch clause). We show that this separation results in significant slowdowns or vast imprecision. The two kinds of analyses are interdependent: neither can be performed accurately without the other. The interdependency leads us to propose a joint handling for performance and precision. We show that our exception analysis is expressible highly elegantly in a declarative form, and can apply to points-to analyses of varying precision. In fact, our specification of exception analysis is “fully precise”, as it models closely the Java exception handling semantics. The necessary approximation is provided only through whichever abstractions are used for contexts and objects in the base points-to analysis. Our combined approach achieves similar precision relative to exceptions (exception-catch links) as the best past precise exception analysis, with a runtime of seconds instead of tens of minutes. At the same time, our analysis achieves much higher precision of points-to information (an average of half as many values for each reachable variable for most of the DaCapo benchmarks) than points-to analyses that treat exceptions conservatively, all at a fraction of the execution time.
Exceptional Situations And Program Reliability
, 2005
"... It is difficult to write programs that behave correctly in the presence of run-time errors. Proper behavior in the face of exceptional situations is important to the reliability of long-running programs. Existing programming language features often provide poor support for executing clean-up code an ..."
Abstract
-
Cited by 15 (1 self)
- Add to MetaCart
It is difficult to write programs that behave correctly in the presence of run-time errors. Proper behavior in the face of exceptional situations is important to the reliability of long-running programs. Existing programming language features often provide poor support for executing clean-up code and for restoring invariants. We present a dataflow analysis for finding a certain class of mistakes made during exceptional situations. We also
present a specification miner for automatically inferring partial notions of what programs should be doing. Finally, we propose and evaluate a new language feature, the compensation stack, to make it easier to write solid code in the presence of run-time errors. We give a dataflow analysis for finding a certain class of exception-handling mis-takes: those that arise from a failure to release resources or to clean up properly along all paths. Many real-world programs violate such resource usage rules because of incorrect exception handling. Our flow-sensitive analysis keeps track of outstanding obligations along
program paths and does a precise modeling of control flow in the presence of exceptions. Using it, we have found over 800 exception handling mistakes in almost 4 million lines of
Java code. The analysis is unsound and produces false positives, but a few simple filtering rules suffice to remove them in practice. The remaining mistakes were manually verified. These mistakes cause sockets, files and database handles to be leaked along some paths.
Specifications are necessary in order to find software bugs using program verification tools. We give a novel automatic specification mining algorithm that uses information
about exception handling to learn temporal safety rules. Our algorithm is based on the observation that programs often make mistakes along exceptional control-flow paths, even when they behave correctly on normal execution paths. We show that this focus improves the miner’s effectiveness at discovering specifications beneficial for bug finding. We present quantitative results comparing our technique to four existing miners. We highlight assumptions made by various miners that are not always borne out in practice. Additionally, we apply our algorithm to existing Java programs and analyze its ability to learn specifications
that find bugs in those programs. In our experiments, we find filtering candidate specifications to be more important than ranking them. We find 430 bugs in 1 million lines of code. Notably, we find 250 more bugs using per-program specifications learned by our algorithm
than with generic specifications that apply to all programs.
We present a characterization of the most common causes of those bugs and discuss the limitations of exception handling, finalizers and destructors. Based on that characterization we propose a programming language feature, the compensation stack, that keeps track of obligations at run time and ensures that they are discharged. Finally, we present case studies to demonstrate that this feature is natural, efficient, and can improve reliability; for example, retrofitting a 34,000-line program with compensation stacks resulted in a 0.5% code size decrease, a surprising 17% speed increase (from correctly deallocating resources in the presence of exceptions), and more consistent behavior.
Practical Exception Specifications
"... Abstract. Exception specifications can aid in the tasks of writing correct exception handlers and understanding exceptional control flow, but current exception specification systems are impractical in a number of ways. In particular, they are too low-level, too heavyweight, and do not provide adequa ..."
Abstract
-
Cited by 14 (1 self)
- Add to MetaCart
(Show Context)
Abstract. Exception specifications can aid in the tasks of writing correct exception handlers and understanding exceptional control flow, but current exception specification systems are impractical in a number of ways. In particular, they are too low-level, too heavyweight, and do not provide adequate support for describing exception policies. We have identified the essential properties of a practical exception specification system and we present a methodology and tool that provides integrated support for specifying, understanding, and evolving exception policies. The annotations required of the programmer are lightweight and easier to maintain than those of current systems; in our studies we observed a 50 % to 93 % reduction in annotations. By leveraging these annotations, our system provides scalable support for understanding exception flow and for modifying exception annotations. 1
An empirical study of the robustness of inter-component communication in Android
- In Proc. DSN
, 2012
"... Abstract—Over the last three years, Android has established itself as the largest-selling operating system for smartphones. It boasts of a Linux-based robust kernel, a modular framework with multiple components in each application, and a security-conscious design where each application is isolated i ..."
Abstract
-
Cited by 9 (0 self)
- Add to MetaCart
(Show Context)
Abstract—Over the last three years, Android has established itself as the largest-selling operating system for smartphones. It boasts of a Linux-based robust kernel, a modular framework with multiple components in each application, and a security-conscious design where each application is isolated in its own virtual machine. However, all of these desirable properties would be rendered ineffectual if an application were to deliver erroneous messages to targeted applications and thus cause the target to behave incorrectly. In this paper, we present an empir-ical evaluation of the robustness of Inter-component Commu-nication (ICC) in Android through fuzz testing methodology, whereby, parameters of the inter-component communication are changed to various incorrect values. We show that not only exception handling is a rarity in Android applications, but also it is possible to crash the Android runtime from unprivileged user processes. Based on our observations, we highlight some of the critical design issues in Android ICC and suggest solutions to alleviate these problems. Keywords-android, fuzz, security, smartphone, robustness, exception
Sound and Precise Malware Analysis for Android via Pushdown Reachability and Entry-Point Saturation
"... Sound malware analysis of Android applications is challeng-ing. First, object-oriented programs exhibit highly inter-procedural, dynamically dispatched control structure. Sec-ond, the Android programming paradigm relies heavily on the asynchronous execution of multiple entry points. Exist-ing analys ..."
Abstract
-
Cited by 9 (3 self)
- Add to MetaCart
(Show Context)
Sound malware analysis of Android applications is challeng-ing. First, object-oriented programs exhibit highly inter-procedural, dynamically dispatched control structure. Sec-ond, the Android programming paradigm relies heavily on the asynchronous execution of multiple entry points. Exist-ing analysis techniques focus more on the second challenge, while relying on traditional analytic techniques that suffer from inherent imprecision or unsoundness to solve the first. We present Anadroid, a static malware analysis frame-work for Android apps. Anadroid exploits two techniques to soundly raise precision: (1) it uses a pushdown system to precisely model dynamically dispatched interprocedural and exception-driven control-flow; (2) it uses Entry-Point Satu-ration (EPS) to soundly approximate all possible interleav-
Changing Java’s Semantics for Handling Null Pointer Exceptions
"... We envision a world where no exceptions are raised; instead, language semantics are changed so that operations are total functions. Either an operation executes normally or tailored recovery code is applied where exceptions would have been raised. As an initial step and evaluation of this idea, we p ..."
Abstract
-
Cited by 8 (2 self)
- Add to MetaCart
(Show Context)
We envision a world where no exceptions are raised; instead, language semantics are changed so that operations are total functions. Either an operation executes normally or tailored recovery code is applied where exceptions would have been raised. As an initial step and evaluation of this idea, we propose to transform programs so that null pointer dereferences are handled automatically without a large runtime overhead. We increase robustness by replacing code that raises null pointer exceptions with error-handling code, allowing the program to continue execution. Our technique first finds potential null pointer dereferences and then automatically transforms programs to insert null checks and error-handling code. These transformations are guided by composable, context-sensitive recovery policies. Errorhandling code may, for example, create default objects of the appropriate types, or restore data structure invariants. If no null pointers would be dereferenced, the transformed program behaves just as the original. We applied our transformation in experiments involving multiple benchmarks, the Java Standard Library, and externally reported null pointer exceptions. Our technique was able to handle the reported exceptions and allow the programs to continue to do useful work, with an average execution time overhead of less than 1 % and an average bytecode space overhead of 22%. 1.
On Exceptions, Events and Observer Chains
"... Modular understanding of behaviors and flows of exceptions may help in their better use and handling. Such reasoning tasks about exceptions face unique challenges in event-based implicit invocation (II) languages that allow subjects to implicitly invoke observers, and run the observers in a chain. I ..."
Abstract
-
Cited by 4 (2 self)
- Add to MetaCart
(Show Context)
Modular understanding of behaviors and flows of exceptions may help in their better use and handling. Such reasoning tasks about exceptions face unique challenges in event-based implicit invocation (II) languages that allow subjects to implicitly invoke observers, and run the observers in a chain. In this work, we illustrate these challenge in Ptolemy and propose Ptolemyχ that enables modular reasoning about behaviors and flows of exceptions for event announcement and handling. Ptolemyχ’s exception-aware specification expressions and boundary exceptions limit the set of (un)checked exceptions of subjects and observers of an event. Exceptional postconditions specify the behaviors of these exceptions. Greybox specifications specify the flows of these exceptions among the observers in the chain. Ptolemyχ’s type system and refinement rules enforce these specifications and thus enable its modular reasoning. We evaluate the utility of Ptolemyχ’s exception flow reasoning by applying it to understand a set of aspect-oriented (AO) bug patterns. We also present Ptolemyχ’s semantics including its sound static semantics.
