Static analysis tools generate a large number of alarms that require manual inspection. In prior work, repositioning of alarms is proposed to (1) merge multiple similar alarms together and replace them by a fewer alarms, and (2) report alarms as close as possible to the causes for their generation. The premise is that the proposed merging and repositioning of alarms will reduce the manual inspection effort. To evaluate the premise, this paper presents an empirical study with 249 developers on the proposed merging and repositioning of static alarms. The study is conducted using static analysis alarms generated on$C$programs, where the alarms are representative of the merging vs. non-merging and repositioning vs. non-repositioning situations in real-life code. Developers were asked to manually inspect and determine whether assertions added corresponding to alarms in$C$code hold. Additionally, two spatial cognitive tests are also done to determine relationship in performance. The empirical evaluation results indicate that, in contrast to expectations, there was no evidence that merging and repositioning of alarms reduces manual inspection effort or improves the inspection accuracy (at times a negative impact was found). Results on cognitive abilities correlated with comprehension and alarm inspection accuracy.

Static analysis tools help to detect common pro-gramming errors but generate a large number of false positives. Moreover, when applied to evolving software systems, around 95 % of alarms generated on a version are repeated, i.e., they have also been generated on the previous version. Version-aware static analysis techniques (VSATs) have been proposed to suppress the repeated alarms that are not impacted by the code changes between the two versions. The alarms reported by VSATs after the suppression, called delta alarms, still constitute 63% of the tool-generated alarms. We observe that delta alarms can be further postprocessed using their corresponding code changes: the code changes due to which VSATs identify them as delta alarms. However, none of the existing VSATs or alarms postprocessing techniques postprocesses delta alarms using the corresponding code changes. Based on this observation, we use the code changes to classify delta alarms into six classes that have different priorities assigned to them. The assignment of priorities is based on the type of code changes and their likelihood of actually impacting the delta alarms. The ranking of alarms, obtained by prioritizing the classes, can help suppress alarms that are ranked lower, when resources to inspect all the tool-generated alarms are limited. We performed an empirical evaluation using 9789 alarms generated on 59 versions of seven open source C applications. The evaluation results indicate that the proposed classification and ranking of delta alarms help to identify, on average, 53 % of delta alarms as more likely to be false positives than the others.

Static analysis tools are useful to detect common programming errors. However, they generate a large number of false positives. Postprocessing of these alarms using a model checker has been proposed to automatically eliminate false positives from them. To scale up the automated false positives elimination (AFPE), several techniques, e.g., program slicing, are used. However, these techniques increase the time taken by AFPE, and the increased time is a major concern during application of AFPE to alarms generated on large systems.To reduce the time taken by AFPE, we propose two techniques. The techniques achieve the reduction by identifying and skipping redundant calls to the slicer and model checker. The first technique is based on our observation that, (a) combination of application-level slicing, verification with incremental context, and the context-level slicing helps to eliminate more false positives; (b) however, doing so can result in redundant calls to the slicer. In this technique, we use data dependencies to compute these redundant calls. The second technique is based on our observation that (a) code partitioning is commonly used by static analysis tools to analyze very large systems, and (b) applying AFPE to alarms generated on partitioned-code can result in repeated calls to both the slicer and model checker. We use memoization to identify the repeated calls and skip them.The first technique is currently under evaluation. Our initial evaluation of the second technique indicates that it reduces AFPE time by up to 56%, with median reduction of 12.15%.

The large number of alarms reported by static analysis tools is often recognized as one of the major obstacles to industrial adoption of such tools.

Static analysis tools are widely used in practice to improve the quality and reliability of software through early detection of defects. However, the number of alarms generated is a major concern because of the cost incurred in their manual inspection required to partition them into true errors and false positives. In this paper, we propose a static analysis to identify the causes of alarms generated by a client static analysis. This simplifies the manual inspections and reduces the cost involved. The proposed analysis involves the following: (1) modeling the basic reasons for alarms as alarm cause points of several types, (2) ranking these cause points based on three different metrics, (3) a workflow in which a user answers queries about the cause points and the answers are used in subsequent round of the client analysis. The collaboration between the user and the client analysis helps the tool to resolve the unknowns encountered during the analysis and weeding out the alarms. It also helps the user expedite the manual inspections of alarms. Further, the ranking of cause points helps to prioritize the alarms. Our experimental evaluation in several settings demonstrated that the proposed approach (a) reduces manual effort by 23% to 72% depending on various parameters, with an average reduction of 42%, and (b) is also effective in identifying the alarms that are more likely to be true errors.

Static analysis tools have showcased their importance and usefulness in automated detection of code anomalies and defects. However, the large number of alarms reported and cost incurred in their manual inspections have been the major concerns with the usage of static analysis tools. Existing studies addressing these concerns differ greatly in their approaches to handle the alarms, varying from automatic postprocessing of alarms, supporting the tool-users during manual inspections of the alarms, to designing of light-weight static analysis tools. A comprehensive study of approaches for handling alarms is, however, not found. In this paper, we review 79 alarms handling studies collected through a systematic literature search and classify the approaches proposed into seven categories. The literature search is performed by combining the keywords-based database search and snowballing. Our review is intended to provide an overview of various alarms handling approaches, their merits and shortcomings, and different techniques used in their implementations. Our findings include that the categorized alarms handling approaches are complementary and they can be combined together in different ways. The categorized approaches and techniques employed in them can help the designers and developers of static analysis tools to make informed choices.

Bug detection using static analysis has been found useful in practice for ensuring software quality and reliability. However, it often requires sifting through a large number of warnings. This can be handled by generating an assertion corresponding to each warning and verifying the assertion using a model checker to classify the warning as an error or a false positive. Since model checking over larger code fragments is non-scalable and expensive, it is useful to model check a given assertion with a small calling context length. For this, the variables receiving values from outside the context are initialized with arbitrary values generated by non-deterministic choice functions. The calling context length is then gradually increased on a need basis to include callers higher up in the call chains. While this aids scalability by keeping the calling context as small as possible, it requires multiple calls to model checker for the same assertion, requiring a considerable amount of time. We present a static analysis to expedite false positive elimination. It is based on the following observation: When the variables involved in an assertion are allowed to take arbitrary values at the point of assertion, the assertion is most likely to be violated by some or the other combination of values. In such cases, usage of a model checker is redundant as it does not aid in resolution of the corresponding warning. Our data flow analysis identifies (an over-approximated set of) such variables using a novel lattice so that model checking of assertions involving such variables can be avoided. Our empirical evaluation demonstrates that, on an average, the proposed static analysis avoids 49.49% of the total model checking calls, and it reduces the false positives elimination time by 39.28%. However, this gain is achieved at the cost of missing 2.78% false positives which could have been eliminated otherwise.

Static analysis tools are widely used in practice due to their ability to detect defects early in the software development life-cycle and that too while proving absence of defects of certain patterns. There exists a large number of such tools, and they are found to be varying depending on several tool characteristics like analysis techniques, programming languages supported, verification checks performed, scalability, and performance. Many studies about these tools and their variations, have been performed to improve the analysis results or figure out a better tool amongst a set of available static analysis tools. It is our observation that, in these studies only the aforementioned tool characteristics are considered and compared, and other implementational variations are usually ignored. In this paper, we study the implementational variations occurring among the static analysis tools, and experimentally demonstrate their impact on the tool characteristics and other analysis related attributes. The aim of this paper is twofold - a) to provide the studied implementational variations as choices, along with their pros and cons, to the designers or developers of static analysis tools, and b) to provide an educating material to the tool users so that the analysis results are better understood.

While software verification using static analysis tools has proved its significance in early defect detection, the tools often fail to analyze many real world systems. Clustering, breaking a system into multiple clusters, is commonly used technique to scale these tools to large systems. Due to the imprecise nature of static analysis and the conservative approach taken for the inter-cluster communication (data sharing), a large number of analysis warnings are generated. All these reported warnings need to be reviewed manually to check if they represent a defect, and it is a time consuming process. We observe many of the reported warnings are common to multiple clusters and reviewing each of them individually incurs redundancy. We present an approach to improve the manual review process by eliminating the redundancy. This is achieved by grouping the inter-cluster common warnings such that review of a grouped warning under given constraint guarantees same review judgment for the other cluster warnings in the same group. Empirical results obtained with the presented approach indicate that -- a) on an average, 45% of total warnings are common to multiple clusters, and b) with the proposed grouping technique, the manual efforts required to review these common warnings are reduced by 60%.

Static analysis has been successfully employed in software verification, however the number of generated warnings and cost incurred in their manual review is a major concern. In this paper we present a novel idea to reduce manual review efforts by identifying redundancy in this review process. We propose two partitioning techniques to identify redundant warnings - 1) partitioning of the warnings with each partition having one leader warning such that if the leader is a false positive, so are all the warnings in its partition which need not be reviewed and 2) further partitioning the leader warnings based on similarity of the modification points of variables referred to in their expressions. The second technique makes the review process faster by identifying further redundancies and it also makes the reviewing of a warning easier due to the associated information of modification points. Empirical results obtained with these grouping techniques indicate that, on an average, 60% of warnings are redundant in the review context and skipping their review would lead to a reduction of 50-60% in manual review efforts.