A Case Study of Dynamic Analysis to Locate Unexpected Side Effects Inside of Frameworks

A Case Study of Dynamic Analysis to Locate Unexpected Side Effects Inside of Frameworks

Izuru Kume, Masahide Nakamura, Naoya Nitta, Etsuya Shibayama
Copyright: © 2015 |Pages: 15
DOI: 10.4018/IJSI.2015070103
OnDemand:
(Individual Articles)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

Recently many frameworks are deployed without proper documents to explain their correct usage. In the absence of proper documents, application developers often write code to call a framework API in a wrong way. Such a wrong API call tends to bring about a failure after its complex chain of infection inside of a framework. The complexity and the lack of implementation knowledge about a framework make it difficult for application developers to debug this kind of failure. In the preceding study the authors focused on unexpected side effects that are caused by wrong API calls and bring about failures, and developed a dynamic analysis technique to detect such side effects. In this paper, the authors introduce a case study to find a wrong API call using our technique.
Article Preview
Top

Preliminary

Operations, Statements, and Dependency

We assume that frameworks and their applications are implemented in Java language. Java objects consist of class instances and arrays. Operations on objects are method invocations (except for static methods), and accesses to their instance variables or array components. An operation is expressed as a statement or an expression in a statement.

Parameters of a method invocation consist of its receiver (if any) and arguments. We call instance variables and array components persistent variables. When a persistent variable of an object is accessed to assign or get a value, then we say that the object is used as a carrier of the value, and that the object carries the value.

In addition to ordinary dependency among statements (Tip, 1995), we introduce new kinds of dependency among operations and statements. A get operation on a persistent variable depends on the operation that assigned the got value to the persistent variable. A method invocation whose receiver is not null executes the method body bound at runtime based on the receiver class. Thus method receivers work in a similar way to operands of conditional branching statements.

A value carrier itself may have been carried by another object, which is the carrier of the carrier of the value. We may further get the carrier of the carrier of the carrier of the value. For a carried value, we can thus obtain a sequence of references of persistent variables which have brought the value. We call such a sequence a reference path to the value or its carrier.

Complete Article List

Search this Journal:
Reset
Volume 12: 1 Issue (2024)
Volume 11: 1 Issue (2023)
Volume 10: 4 Issues (2022): 2 Released, 2 Forthcoming
Volume 9: 4 Issues (2021)
Volume 8: 4 Issues (2020)
Volume 7: 4 Issues (2019)
Volume 6: 4 Issues (2018)
Volume 5: 4 Issues (2017)
Volume 4: 4 Issues (2016)
Volume 3: 4 Issues (2015)
Volume 2: 4 Issues (2014)
Volume 1: 4 Issues (2013)
View Complete Journal Contents Listing