Databases Reference
In-Depth Information
specifications and identify error-handling violations. The framework presented
in the previous section does not consider error paths or generate error traces.
In this section, we adapt the framework presented in the previous section to
generate and distinguish error traces from normal traces. Normal paths and
error paths are distinguished and specifications are learned from normal paths
as programmers often make mistakes along error paths [14, 31, 56, 60].
Incorrect handling of errors incurred after API invocations can lead to se-
rious problems such as system crashes, leakage of sensitive information, and
other security compromises. API errors are usually caused by stressful envi-
ronment conditions, which may occur in forms such as high computation load,
memory exhaustion, process-related failures, network failures, file system fail-
ures, and slow system response. As a simple example of incorrect API error
handling, a send procedure, which sends the content of a file across the network
as packets, might incorrectly handle the failure of the
socket
API (the
socket
API can return an error value of
-1
, indicating a failure), if the send proce-
dure returns without releasing system resources such as previously allocated
packet buffers and opened file handlers. Unfortunately, error handling is the
least understood, documented, and tested part of a system. Toy's study [56]
shows that more than 50% of all system failures in a telephone switching ap-
plication are due to incorrect error-handling algorithms. Cristian's survey [22]
reports that up to two-thirds of a program may be devoted to error detec-
tion and recovery. Hence, correct error handling should be an important part
of any reliable software system. Despite the importance of correct error han-
dling, programmers often make mistakes in error-handling code [14, 31, 60].
Correct handling of API errors can be specified as formal specifications verifi-
able by static checkers at compile time. However, due to poor documentation
practices, API error-handling specifications are often unavailable or imprecise.
There are three main unique challenges in automatically mining API error-
handling specifications from source code. (1) Mining API error-handling speci-
fications, which are usually temporal in nature, require identifying API details
from source code such as (a) critical APIs (APIs that fail with errors), (b)
different error checks that should follow such APIs (depending on different
API error conditions), and (c) proper error handling or clean up in the case of
API failures, indicated by API errors. Furthermore, clean up APIs might de-
pend on the APIs called before the error is handled. Static approaches [59, 60]
exist for mining or checking API error-handling specifications from software
repositories implemented in object-oriented languages such as Java. Java has
explicit exception-handling support and the static approaches mainly ana-
lyze the
catch
and
finally
blocks to mine or check API error-handling spec-
ifications. Procedural languages such as C do not have explicit exception-
handling mechanisms to handle API errors, posing additional challenges for
automated specification mining: API details are often scattered across dif-
ferent procedures and files. Manually mining specifications from source code
becomes hard and inaccurate. Hence, we need inter-procedural techniques to
mine critical APIs, different error checks, and proper clean up from source
Search WWH ::
Custom Search