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

of all possible traces could be huge in practice. Our adaptation only generates
L traces randomly from the set of all possible traces in a given compilable unit.
The traces contain the probable clean up APIs and the APIs related to them,
if any. Finally, as API error-handling specifications can be conditional, the
clean up for an API might depend on the actual return value of the API. As a
simple example, for the malloc API, the API free is called only along paths in
which the return value of malloc is not NULL (condition). Hence, normal paths
(normal traces) are associated with their corresponding conditions involving
API return values. The conditions, along with API sequences, form a part of
normal traces and are used in the specification mining stage, explained next.

5.3.2.2 Specication Mining

The specification mining stage mines error-check and multiple-API spec-
ifications from the static traces (Steps 7-8). The scenario extraction and se-
quence mining are performed in Step 8.
Step 7 - Mine error-check specifications. Our adaptation generates
error-check specifications (procedure generateErCS , Step 7, Figure 5.19) as
Finite State Machines (FSM,F ErCS ) from the computed API-error check set.
The FSMs representing the error-check specifications specify that each critical
API should be followed by the correct error checks.
Step 8 - Mine multiple-API specifications. Our adaptation mines
multiple-API specifications from normal traces (procedure generateMAS , Step
8, Figure 5.19) as FSMs (F MAS ). Normal traces include the probable clean
up APIs (PC), APIs related to the set PC, and the conditions (involving API
return values). The main observation used in mining multiple-API specifica-
tions from normal traces is that programmers often make mistakes along error
paths [14,31,56,60]. Hence, our adaptation mines related APIs from only nor-
mal traces and not from error traces. However, a single normal trace generated
by the trace generator might involve several API scenarios, being often inter-
spersed. A scenario (see Section 5.3.1) is a set of related APIs in a given trace.
Our adaptation separates different API scenarios from a given normal trace,
so that each scenario can be fed separately to the miner. We use a scenario ex-
traction algorithm (procedure extractScenarios , Step 8, Figure 5.19) 5.2.2.5
that is based on identifying producer-consumer chains among APIs in the
trace. The algorithm is based on the assumption that an API and its corre-
sponding clean up APIs have some form of data dependencies between them
such as a producer-consumer relationship. Each producer-consumer chain is
generated as an independent scenario. For example, in Figure 5.17, the API
XftFontOpenName (Line 9) produces aafont , which is consumed by the API
XftFontClose (Line 17). The APIs XftFontOpenName and XftFontClose are gen-
erated as an independent scenario.
Our adaptation mines multiple-API specifications from independent sce-
narios using frequent-sequence mining (procedure sequenceMine , Step 8, Fig-
ure 5.19). Let IS be the set of independent scenarios. We apply a frequent