Databases Reference
In-Depth Information
traces generated by our adaptation are shown in Columns 3 (ErExT) and 4
(ErRT) of Figure 5.20, respectively. To evaluate trace generation, we man-
ually inspected the source code for each error exit-trace produced by our
adaptation and each error exit-trace missed by our adaptation. Error exit-
traces missed by our adaptation can be determined by manually identifying
the exit statements in the analyzed program not found in any of the gener-
ated error exit-traces. There are five sub-columns in Column 3 (ErExT):
(total number of error exit-traces generated or missed by our adaptation),
op
(total number of error exit-traces actually generated by our adaptation), FN
=
op
(total number of error exit-traces missed by our adaptation), FP
(false positives: generated traces that are not actually error exit-traces), and
IP (inter-procedural: number of traces in which the API invocation, API-error
check (AEC), and error blocks were scattered across procedure boundaries).
The number of false negatives (FN) and false positives (FP) were low,
at 12% (88/748) and 10% (65/660), respectively. The main reason for false
negatives in the traces generated by our adaptation is the lack of aliasing
and pointer analysis. For example, in
xkbvleds/utils.c
, the variable
outDpy
takes the return value of the API
XtDisplay
. Then the value of
outDpy
is
assigned to another variable
inDpy
, and
inDpy
is compared to
NULL
. If
inDpy
is
NULL
, a user-dened procedure
uFatalError
is called, which then calls
exit
.
Our adaptation did not capture the aliasing of
outDpy
to
inDpy
, and hence
the trace was missed. However, as the number of false negatives was low, our
adaptation still generated enough traces for the mining process. Some of the
traces generated by our adaptation were not error exit-traces, leading to false
positives. For example, in
tftp/tftpd.c
, the variable
f
(process id) takes the
return value of the API
fork
. The program exits on
f>0
(parent process; not an
error). Although the trace was generated by our adaptation, it is not an error
exit-trace (
fork
fails with a negative integer). However, as the number of false
positives was low, false error exit-traces were pruned by the mining process.
41% (306/748) of all the error exit-traces were scattered across procedure
boundaries, highlighting the importance of inter-procedural trace generation.
Specifically, all error exit-traces from the
postfix
package crossed procedure
boundaries.
Our adaptation extracts the set of probable clean up APIs from the er-
ror traces (Step 5, Figure 5.19). After discarding string-manipulating APIs
(such as
strcmp
and
strlen
), printing APIs (such as
printf
and
fprintf
), and
error-reporting APIs (such as
perror
), which frequently appear (but unimpor-
tant) in the error blocks, our adaptation extracted 36 APIs as probable clean
up APIs. Our adaptation used probable clean up APIs in generating normal
traces (NT). For each compilable unit in the analyzed packages, our adapta-
tion randomly generated 20 normal traces, ensuring there are enough distinct
traces for mining. Our adaptation discarded 14/36 APIs after mining the nor-
mal traces (NT) with one of the following reasons: (1) insucient call sites
and hence, insucient number of traces to mine from (for example, the API
XEClearCtrlKeys
had only two traces), (2) no temporal dependencies with any
Search WWH ::
Custom Search