Static API Specification Mining: Exploiting Source Code Model Checking - Mining Software Specifications: Methodologies and Applications - page 143

errnoChk for an API call site, then our adaptation generates the shortest trace
for each of the checks. The triggerFcaptures the retValChk , errnoChk , and
the code block after these checks, even if they are scattered across procedure
boundaries. However, the traces generated by this step can also have traces
where retValChk or errnoChk is followed by a normal return of the enclosing
procedure. Such traces, which are not error traces, are pruned out in the next
step.
Steps 2, 3, and 4 - Process error traces. Our adaptation easily ex-
tracts error exit-traces from error traces (procedure getErExT , Step 2, Fig-
ure 5.19): Error traces that end with an exit call are error exit-traces. We
assume that the API retValChk or errnoChk , which precedes an exit call in
an error-exit trace, is an API-error check. We then distinguish between the
true and false branches of the API-error check. For example, in Figure 5.16,
since exit(...) appears in the true branch of AEC( recvfrom ) ( if(cc<0) ), we
assume that <0 is the error return value (API error) of recvfrom . For each
API, our adaptation records API-error check with majority occurrences (pro-
cedure majorityMine , Step 3, Figure 5.19) among error exit-traces (procedure
getAECSet , Step 3, Figure 5.19). As mentioned in the previous step, the traces
generated in Step 1 can also have traces where retValChk or errnoChk is fol-
lowed by a normal return of the enclosing procedure. Our adaptation uses the
API-error check set computed from error exit-traces to prune out such traces
to obtain error return-traces (procedure getErRT , Step 4, Figure 5.19).
Step 5 - Identify critical APIs and probable clean up APIs from
error traces. Our adaptation computes the set R (critical APIs) and the
set PC (probable clean up APIs) in this step (procedure getRandPc , Step 5,
Figure 5.19). The set R of critical APIs is easily computed from error exit-
traces and error return-traces. A key observation of our adaptation is that it
is much easier to find clean up APIs along error paths than normal paths. It is
because, on API failures, before the program exits or the enclosing procedure
returns, the primary concern is clean up. Along normal paths, however, it is
dicult to separate clean up APIs from other APIs. Hence, our adaptation
identifies probable clean up APIs (the set PC) from the error traces. The term
probable indicates that the APIs that occur in error blocks need not always be
clean up APIs. The mining phase prunes out the non-clean-up APIs from the
set PC. In the next step, we show how our adaptation identifies APIs related
to the probable clean up APIs. These related APIs occur prior to API-error
checks in the source code.
Step 6 - Generate normal traces. A normal trace starts from the
beginning of the main procedure and ends at the end of the main procedure.
The procedure TG uses the trigger FSM, sayF(Step 6, Figure 5.19), to generate
normal traces (NT) from the program source code (P). The edges for State 2
in the triggerFare critical (set R) and probable clean up APIs (set PC). Our
adaptation generates normal traces (involving critical and probable clean up
APIs) randomly up to a user-specified upper bound L (procedure getRandomL ,
Step 6, Figure 5.19), inter-procedurally. An upper bound is required as the set