OF ALARM CORRELATIONS BASED ON STATIC DEFECT DETECTION

refined semantic (line 2). As described earlier, if an alarm reported at the defect detection phase is not reported by the procedure (line 3) under the abstract refined semantic with an alarm (line 5-6), we say abstractly correlates with and is denotedly correlates with and is denoted


Introduction
Traditional static defect detection tools can detect software defects [1 ÷ 4], e.g., null-pointer dereference (NPD), invalid arithmetic operations (IAO), and memory leak (ML), and generate independent atomic warnings automatically, but they do not take the influences among different alarms into account and identify the correlations among alarms [5].In an actual software testing process, the verification of software warnings is still done manually while the code around the alarm can be complex sometimes and it is time-consuming.For the large newly developed software, hundreds, or even thousands of warnings are generated by tools, but generated reports are processed at a very low speed.Excessive warning generation and a large proportion of incorrect warnings may cause developers to reject the use of static analysis tools.Helping users in the alarm verification is a major challenge for current static defect detection tools [6,7].
In this paper, we propose a framework for the investigation of the alarms, so as to help classify them by their correlations.We explore relationships among alarms for verification, show that a correlation can exist between alarms.Once we find these groups of alarms, we only need to check whether their dominant alarm is false positive or a real defect.
Our goal is to provide support in the alarm investigation process, especially in how to reduce alarm identification burden.We propose an approach resorting to automatic, sound static analysis techniques to refine an initial abstract semantics by an alarm reported by our static analyzer.If another alarm does not take place in a refined semantics, we believe they are correlated.
The contribution of the paper is both theoretical and practical.The details are in the following:  We provide two rigorous definitions of alarm correlation and abstract alarm correlation, and then prove the soundness based on abstract interpretation. We propose an approach to automatically computing correlations based on forward analysis, state slicing and input constraint.Meanwhile, a sound alarm correlation framework is presented.It is general and applicable to any semantic-based static defect detection tools. For the inter-procedural alarm correlation calculation, we present a procedure correlation summary model and describe a general technique for constructing and instantiating, which makes our approach distinguished from others. A prototype of our framework is implemented as an extension to DTS [8 − 10], a general automatic static defect detection tool for GCC programs developed by ourselves.Preliminary experimental results are encouraging.We choose one common semantic alarm as a case study and prove that the approach can effectively reduce 34,23 % of the workload to identify all alarms.
The rest of this paper is organized as follows: Section 2 gives one illustrative motivation example.Section 3 presents the fundamentals of alarm correlation, introducing a procedure correlation summary model for inter-procedural alarm correlation calculation.Algorithms for computing alarm correlation are presented in Section4.In Section 5, we introduce the experimental results.Technical Gazette 22, 2(2015), 311-318 Related work and conclusion are presented in Section 6 and Section 7.

Motivating example and insight
In this section, we show that a correlation can exist among alarms.We provide an informal overview of the various challenges faced with alarm verification while leveraging alarm correlations technique.We present main ideas at a semi-technical level using a motivation example.Fig. 1 shows an example of alarm correlations found in httpd-2.4.4.It presents how alarm investigation efforts are greatly reduced.These 3 alarms are reported by the static defect detection tool (DTS) and these correlation relationships are discovered automatically by correlation algorithms.
In the program snippet (a) of Fig. 1, the procedure is summarized first with a return value by the analyzer at line 359.At line 361 and 362, two NPD alarms are reported.The variable s value is returned on line 367, and procedure is summarized with a return value by the analyzer.Then the function is called to allocate the memory in other procedures (see the program snippet (b)) and the analyzer reports the alarm .However, in fact, the procedure will never fail to allocate memory, since in the case of httpd-2.4.4.If the allocation fails, a function is registered that gracefully shuts down the particular server process, and is in the process guaranteed to never return .So these 3 alarms are all false positives.If they are reported separately, the end user will have to investigate them for 3 times while the code around the alarm can be complex sometimes.
Obviously, in procedure (Fig. 1(a)), if is a false positive, the will also be the one.We call them as the intra-procedural correlated.Meanwhile, has an inter-procedural correlation with , and is the predominant alarm.If the predominant alarm is proved false, then others correlated with it are also false.So we only need to identify instead of all alarms, seeing that alarm correlation can improve the efficiency of warning verification.
According to the analysis above, the key technical challenges facing alarm correlation concern two aspects.First, how to calculate the alarm correlation between two alarms with uniformity and accuracy, where indicates the isomorphic representation whatever alarms are false positives or true errors.Meanwhile, accuracy implies computational results are reliable.Second, how to construct a general-purpose procedure correlation summary for the inter-procedural alarm correlation calculation is a key issue.Our algorithm overcomes these challenges with the following insights.
DTS analyzes programs based on a forward dataflow analysis and takes the external input into account in a real world program, which also might affect the results at a precise time in the execution.
dealing with these external inputs is based on over-approximating techniques.It is difficult to capture the impact of one alarm on another directly.In this study, we take the advantage of the ideas of external input constraints.More specifically, by giving two alarms α and β, we slice α's error state and treat the at a program point as an external input, then get a refined semantic based on an assumed external input constraints.We just judge whether β is reported at the refined semantic.If β is reported, we call β is correlated with α.
Each alarm's might affect its procedures and its concrete call site contexts in two aspects: (1) the in one call procedure might cause side effects to actual-parameters and global variables, (2) the might affect the procedure's return value, potential interrupt instructions, the caller's dataflow and control flow.As a result, by concentrating on the above information, a unified procedure correlation summary model could be constructed, which can uniformly and precisely reflect the call effect of each alarm's in every procedure.

Alarm correlation
In this section, we first briefly describe the background of our static analysis which is the basis of the subsequent sections.In the following, concrete program semantics refers to trace semantics [11,12], which observes the history of each possible computation step by step.Abstract semantics refers to any approximations of trace semantics.According to the research of the pioneers, one single cause of imprecision at some program point often leads to many false alarms in the code reachable from that program point later [6], so a single refinement typically eliminates many false alarms.Furthermore, the same root cause of a defect appears several times in the program.In this section, an alarm correlation notion was formally introduced to optimize static analysis reports, providing the definition of alarm correlation and abstract alarm correlation.

A. Preliminaries
We describe a program with a transition system and assume that a procedure is defined by the data of a tuple .stands for the set of program point of execution; denotes a finite set of variables; denotes a set of values stored in the memory; a function describes the variables and values correspondingly, where .We usually write for the set of execution states and for the set of initial states, where are the entry program points.We should add a special error state since real world programs may crash.We also consider interprocedural programs, that a control state is defined by a pair , where is a calling function name and a syntactic control point.A state in an inter-procedural program is a tuple in .The program semantics formalizes its behaviour and the precision of its description depends on the level of abstraction of the considered semantics and the level of abstraction domains over which the semantics is computed.
An execution of a program is represented with a sequence of execution states, called as a trace; This semantics is accurate but not decidable in abstract interpretation semantics systems.The written stands for the trace semantics of a program , including more detailed introduction of trace semantics see [11].
By giving a program and a safety property, we wish to either validate that the code respects the property, or find an execution path that shows how the code violates the property.The static analyzer over-approximates the set of reachable dangerous states and reports corresponding alarms.
At a program point of program , if , then, the static analysis tool reports an alarm , where and are the abstract semantics of and separately, is an error state function, and .Alarm is a major issue for end users.Indeed, when the analyzer reports an alarm, it could be either a false alarm or a real bug that should be fixed.Currently, the alarm investigation process mainly relies on the manual inspection of variants, partly with a graphical interface.This process turns out to be cumbersome, since even simple alarms may take days to classify [7].In the rest of this section, we explore relationships among alarms for investigation.We define the notion of alarm correlation and abstract correlation.We also prove the soundness of the abstract correlation among these correlated alarms.Once we find these groups of alarms, we only need to check whether their predominant alarm is false positive or a real defect.

B. Correlation Definition
We first give the definition of in concrete semantics, and formally introduce two notions and , then prove the soundness based on abstract interpretation.Finally, this subsection gives the definition of , which establishes the basis for the following implementation in our static analyzer.
In program , if a static analysis tool reports two alarms and respectively from and along a trace of , , suppose alarm will never occur when alarm does not occur, we say that have a correlation relationship with , and write .In static analysis, real faults are often mixed with an overwhelming number of false alarms.By being given two alarms and , there are two situations for alarm correlations: (1) if alarm is always false alarm when alarm is false alarm, we say that is correlated with .We denote the correlation as , i.e. , , and (2) if alarm is always real fault when alarm is real fault, we say that is correlated with .We denote the correlation as , i.e. , .Since the concrete alarm correlation is not computable in general, we use abstract alarm correlation which is sound in replacement of concrete alarm correlation.The idea is that if static analysis tools do not report the alarm from the abstract semantics refined under the assumption that alarm does not occur, we can say that has a concrete correlation with .It is easy to notice that this is correct, because even though the refined abstract semantics is smaller than the original fixpoint, it is still sound abstraction of concrete semantics if the assumption holds.
At some abstract domain, if we cut the error state, the static analysis tool will not report this alarm at this point in the program.In the rest of the section, we define the notion of state slicing and abstract correlation.We also prove the soundness of abstract correlation.
In the program , if a static analysis tool reports an alarm at a program point , we can get a state slicing by slicing the error state at this program point .We can define the , we let for the concrete error state at program point in the execution of the program, denotes a concrete operation of error state slicing.
Accordingly, we can define an : , and we denote for the sound abstract error state slicing operation.In the concrete practice, static analysis tools need to implement this abstract resection operation at some abstract domain.
In a real world application, there can be a lot of external input, which also might affect the results at precise time in the execution of the program.Most present tools deal with these external inputs based on overapproximation techniques.In this study, we take advantage of the ideas of external input constraints, treating the state slicing at a program point as an external input, and then get a based on an assumed external input constraint.
In program , given a set of program points: . An program point is a function , mapping a program point to the set of values that may be read at this point.
allows to select different inputs for different execution contexts at the same program point.The denotation of the input function δ is the set of traces , and such traces satisfy the property that reading an input at label yields a value in .We do not consider the real application of external input.Indeed, we slice the error states as a kind of external input constraints, replacing the original program semantics, denoted as and denotes a finite set of alarm program points, accordingly, input function can be further described: .Consider the case where we slice the error states as a kind of external input constraints, the semantic can be further refined, the refined semantic can be presented as .Suppose is a sound abstraction of , i.e. .The abstraction of the can be defined: , is a sound approximation of , i.e.
. Since concrete correlation is not computable in general, we use an approximation correlation which is sound with respect to concrete correlation.Taking the procedure as an example (Snippet (a) of Fig. 1), the process of defect detection and alarm correlation is shown in the following Figs.2(a) and 2(b).In the left of Fig. 2(a), there are two alarms reported ( and ) at node ( 2) and (3) separately in the procedure , because the variable contains a value.In the left of Fig. 2(b), when we slice the value of , the alarm will not be reported at node (2), also at node (3).So, we can say that npd1 has an intra-procedural correlation with npd2, which denotes as npd1 npd2.C. Inter-procedural alarm correlations achieves both path-sensitive intra-procedural analysis and context-sensitive inter-procedural analysis.
addresses inter-procedural problem by introducing a unified symbolic procedure summary model and describes a general technique for constructing and instantiating.What information to capture in each procedure summary has been carefully tuned so that the summary should not lose any common defect-related behaviour?Because of limited space, we do not explain our inter-procedural analysis, see [8,10] for details.
(1) Procedure correlation summary model As shown in the right of Fig. 3(a), although the procedure summary technology has been successfully used in , it does not take the influence among alarms into account between two procedures.Such as in Fig. 3(b), we slice the error state in parallel when is reported at the node (2).It becomes even more obvious that the affects procedure 's return value and the caller 's dataflow value in the right of figure 3 (b).To be specific, if the return value of is , the value of is also in . So, we can say that have an inter-procedural correlation with , which is denoted as .As discussed in Section 2, an alarm's state slicing might affect its procedure and further lead to two types of call site context transformation, which corresponds to two aspects of our .In a specific invocation to procedure , there is a set of alarms reported.The construction of our alarm follows the following description: means that the 's error state slicing in one callee procedure might cause side effects to actual-parameters and global variables.We consider the error state slicing as a kind of external input constraints, the domain of parameters and global variables can be further refined, the means the parameters and global refined domain information.and indicates that the 's error state slicing might affect the procedure return value and potential interrupt instructions respectively.The and are the refined information of return value and interrupt information accordingly.Each procedure is summarized by convergent fixpoint iteration based on abstract interpretation, so the analyzer can naturally handle arbitrary call cycles from direct or indirect recursive calls. (

2) Correlation summary instantiation
We now show how to perform context-sensitive correlation summary instantiation at concrete call sites.Consider a procedure call , and we have got the correlation summary of callee .The call site context ( ) consists of all dataflow information right before the procedure call sites.While encountering at call site , the precise summary is extracted by comparing and the conditional constraints binding with the summary.Then we leverage the refined correlation summary in two different manners: (1) if the summary information is concrete deterministic abstract domains, we will update the call site context using these fresh dataflows for subsequent detection and (2) if the summary is represented by some symbolic expressions, we employ the reversed mapping function to decide which symbol should be substituted by the actual parameter, and the dataflow iterates continually in this manner [8].

Computing alarm correlation
As shown in the above section, we need to calculate the abstract alarm correlation to reveal the concrete correlations between alarms which are reported by static analyzers.Our approach has three major phases.In the first phase, we employ a data flow analysis to update the state information and refined state information at one node of a . The phase of state updating is shown on the top side of Fig. 3. Next, we run defect detection, and if the static analysis tool reports an alarm, we will go to the final phase and run the alarm correlation computing.We simulate the propagation of the new state along one trace to determine its impact on the occurrence of other alarms.If the alarm reported at the second is not reported under the refined state information set, we report the alarm correlation information and slice out the error state at this alarm point where the alarm occurs.The goal of the third phase is to identify whether an error state that was removed at an alarm point can influence another alarm reported in the second phase.The second and third phases are shown on the bottom side of Fig. 3.

Figure 3 The flowchart of our correlation algorithm
Based on the above idea, we give a specific algorithm to calculate the alarm correlation in this section.We embed our alarm correlation algorithm in the process of defect detection.It takes as input a safety policy set and a .Our goal is to identify all the correlations for the alarms reported by our static analysis tool at each node on .We now describe these algorithms formally.High-level pseudocode for the correlation algorithms is given in the following.In Algorithm 4, procedure is a process of calculating at the abstract refined semantic (line 2).As described earlier, if an alarm reported at the defect detection phase is not reported by the procedure (line 3) under the abstract refined semantic with an alarm (line 5-6), we say abstractly correlates with and is denoted as .

Experimental results
To evaluate the effectiveness and efficiency, we have implemented a prototype of this novel technique as an extension to , a static analysis tool developed by ourselves.
analyzes programs in four stages.First, source codes are preprocessed to an intermediate format by GCC compiler.Second, a compiler-front-end like analyzer generates the $CFG$ and procedure call graph.Third, at the same time with a symbolic interval analysis for generating variants' abstract domain, we summarize each procedure and instantiate the callee summaries at concrete call sites.Finally, the resolver detects potential defects along the control flow graph of the procedure, using the above dataflow information.In this section, we first present the experimental setup and show the results.Then, we analyze the results and give our experimental discussion.

D. Experimental Setup
We choose one type of common software warning null-pointer dereference and ten open source C projects with source code sizes ranging from several to hundreds of thousands of lines for evaluating our method, all of our experiments are done on a 2,4 GHz Intel Xeon Server with 3 GB main memory, running Windows Server 2003.We measured running time using enough repetitions to avoid timer resolution errors.
To quantify the efficiency and precision, the experiments are conducted in two different configurations.
The first configuration employs the original , whereas the second leverages our alarm correlation method.In Tab. 1, the column indicates the total lines of source codes in all source files with suffixes ".c" and ".h", whereas the entries indicate the total lines in the preprocessed files, generated by GCC preprocessor with ".i" suffix.The and entries respectively indicate the analyzing time consumption of original and our alarm correlation method.
The alarms point (in column ) indicates a potential defect, and the entries represent the number of correlated alarms.The intra-procedural correlated alarms are listed in column and the interprocedural correlated alarms are shown in Column .The correlated alarms are grouped by their predominant alarm.The statistic entries with the form ''%'' stand for the investigation decrement ratio after manually distinguished.
Finally, we give a statistics on the last line.For the two configurations, we are more interested in whether some of the unknown alarm correlations could be detected by our alarm correlation technique at a very little consuming time.

E. Experimentation Analysis and Discussion
As shown in TABLE 1, according to the statistics, the 1760 files contain over 0,65 million lines of source code (a parallel 5,4 million lines of intermediate code).All benchmarks were analyzed in 4,2 hours by our original , and reported 2810 alarms, comparison to 4,57 hours by alarm correlation method with an average investigation decrement ratio .Generally, the results of two configurations deliver on their promises: the was fast but the reported alarms are separate; the reported 962 correlated alarms.Next, we will analyze the results of our alarm correlation method from the aspects of effectiveness and efficiency.Our alarm correlation algorithm turns out to be the most effective for ffmpeg-0.4.8 and httpd-2.4.4 (reduced by 45,78 % and 43,04 %) because of the following factors.First, these two projects both many dereferences of structure-typed variables.Second, it is common in these projects that valued dependencies of alarm-related variables propagate from callee to caller.For the example in figure 1, the structure-typed variable (line 359) is dereferenced at line 361 and 362, and its value is returned at the end of function , which would further affect the callers.Our approach to resolve this problem is based on a unified procedure correlation summary model.
Suppose that a tool reports 3000 warnings and each warning requires 3 minutes for inspection, the time to inspect all the warnings will take 18,75 uninterrupted 8-h workdays [13].Originally without the improvements by alarm correlation, the 2810 alarms will take about 18 workdays.Naturally, by applying our approach, there are 962 correlated alarms outputted by the proposed algorithm with only 23 minutes, that is, we save one-third of the total time for identifying all alarms.In summary, the experimental results demonstrate that our alarm correlation method scales well in practice, with an affordable efficiency.

Related work
In this paper, we provide a support in the alarm verification process to identify correlate relationships between alarms and propose a framework for the investigation of the alarms produced by , so as to help classifying them by their correlations [13].
To help with diagnosis, Wei Le [5] show that identifying a causal relationship among faults helps understand fault propagation and group faults of related causes.To our best knowledge, they are the first time to introduce the definition of fault correlation.By propagating the effects of the error state along the program path, they detect the correlation of pairs of alarms.However, Wei Le 's method is not sound, their method is based on symbolic execution techniques, they introduce an external constraint solver to resolve integer constraints stored in the query.Our method is based on abstract interpretation theory and sound.
Rival proposed a method for the investigation of the alarms produced by their static analysis tool [6], so as to help classifying them as true errors or false alarms that are due to the approximation inherent in the static analysis.They refine an initial static analysis into an approximation of a subset of traces that actually lead to an error.If a combination of forward and backward refining analysis allows proving that this set is empty, they can conclude the alarm is false.In this paper, we do not check an alarm.Indeed, we judge a correlation relationship between two alarms.
Our work resembles to Lee 's work in the sense that both works refine the abstraction by exploiting the information about error state [14].We are both trying to classify the alarms by their correlate relationship, but Lee 's method is based on a super control flow graph.They cluster alarms based on a (not all) subset of possible dependencies, and if at the program point , they will abandon the abstract refined alarm trace semantic and alarm information about , which will end up with missing more correlation information.On the other hand, we perform an intra-procedural alarm correlation computing among all alarms in one procedure.Also, we introduce a tag to record the alarm duplication in one procedure.If one alarm was reported many times, it will only be counted once.Our inter-procedural alarm correlation computing is based on an expanded unified symbolic procedure summary model.More details of our analysis can be found in our early works.

Conclusion
This paper addresses an important issue in the usability of static analysis tools: such tools tend to produce voluminous outputs and potential users are often dissuaded from using them because reviewing this output (warnings of different levels of severity) appears to be overwhelming.We present an approach that uses alarm correlation techniques to efficiently identify correlated warnings.Our approach is general enough to be applicable to any static analyzers based on abstract interpretation.The experimental results prove that our method has the effect of reducing 34,23 % of the amount of alarm identification.Using the correlation information, we are able to automate alarm identification that had to be done manually previously.In the future, we plan to optimize our alarm correlation techniques and reveal more complicated correlation situations.

Figure 1
Figure 1 Three Alarms from httpd-2.4.4

Figure 2
Figure 2 Defect detection and alarm correlation of 3 alarms

Table 1
Results of comparison experiment