{'fraction_non_alphanumeric': 0.0339168970207538, 'fraction_numerical': 0.008336624106006756, 'mean_word_length': 5.02232791650152, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A Hybrid Approach to Fine-grained Automated Fault Localization

Fault localization is to identify faulty source code. It could be done on various granularities, e.g., classes, methods, and statements. Most of the automated fault localization (AFL) approaches are coarse-grained because it is challenging to accurately locate fine-grained faulty software elements, e.g., statements. SBFL, based on dynamic execution of test cases only, is simple, intuitive, and generic (working on various granularities). However, its accuracy deserves significant improvement. To this end, in this paper, we propose a hybrid fine-grained AFL approach based on both dynamic spectrums and static statement types. The rationale of the approach is that some types of statements are significantly more/less error-prone than others, and thus statement types could be exploited for fault localization. On a crop of faulty programs, we compute the error-proneness for each type of statements, and assign priorities to special statement types that are steadily more/less error-prone than others. For a given faulty program under test, we first leverage traditional spectrum-based fault localization algorithm to identify all suspicious statements and to compute their suspicious scores. For each of the resulting suspicious statements, we retrieve its statement type as well as the special priority associated with the type. The final suspicious score is the product of the SBFL suspicious score and the priority assigned to the statement type. A significant advantage of the approach is that it is simple and intuitive, making it efficient and easy to interpret/implement. We evaluate the proposed approach on widely used benchmark Defects4J. The evaluation results suggest that the proposed approach outperforms widely used SBFL, reducing the absolute waste effort (AWE) by 9.3% on average.


INTRODUCTION
Fault localization is to identify faulty source code in programs [9,42,46]. Accurate fault localization is critical for bug fixing. Before developers can fix faulty programs, they have to accurately identify faulty source code from the programs. However, manual fault localization is challenging, tedious, and time-consuming [33], especially for inexperienced developers in debugging complex programs developed by others. To this end, a few automated fault localization techniques (called AFL for short) have been proposed [11,29,45]. Such novel approaches have significantly reduced the cost of fault localization, thus also reduced the cost of software debugging that often takes up to 80% of the total software cost [33].
Fault localization could be done on various granularities, e.g., classes [16], methods [19,22], and statements [37]. Most of the automated fault localization approaches are coarse-grained [12] because it is challenging to automatically and accurately locate fine-grained faulty software elements, e.g., statements. For example, with the widely used spectrum-based fault localization techniques (called SBFL for short), developers may have to inspect hundreds of statements manually before a faulty statement is finally identified [37]. The effort wasted in inspecting such bug-free statements is called absolute wasted effort (called AWE for short) [47].
However, some automated approaches, e.g., automated program repair [17,23,35,36,40,41] (called APR for short) requires finegrained fault localization [9]. To the best of our knowledge, most of the ARP tools require statement-level/line-level fault localization. For example, mutation-based ARP tools like PraPR [10] generate candidate patches by applying predefined mutation operators to suspicious statements that are identified by fine-grained fault localization approaches. SimFix [13] requires line-level fault localization to extract the contexts of the faulty source code, and generates candidate patches based on the extracted contexts. As a result, such APR algorithms/tools often leverage the traditional spectrum-based fault localization algorithms although more advanced coarse-grained AFL approaches have been proposed recently [16,19]. Spectrum-based fault localization, based on dynamic execution of test cases only, is simple, intuitive, and generic (working on various granularities). However, its accuracy deserves significant improvement [19,22]. If fine-grained fault localization is inaccurate, automated program repair tools have to generate and validate numerous candidate patches on a large number of bug-free statements before they finally come to the faulty statement. As a result, cost of such APR tools could be unnecessarily high.
To this end, in this paper, we propose an automated, simple, and intuitive hybrid approach (called HybridAFL) to fine-grained fault localization. The rationale of the approach is that some types of statements are significantly more/less error-prone than others, and thus the statement types could be exploited for fault localization. Further more, such static type information may complement dynamic spectrums of test case executions [14]. Consequently, the proposed approach exploits both dynamic spectrums of test case executions and static statement types. On a crop of faulty programs, we leverage simple statistics to compute the error-proneness for each type of statements, and assign priorities to special statement types that are steadily more/less error-prone than others. For a given faulty program under test, we first leverage traditional spectrum-based fault localization algorithm to identify all suspicious statements and to compute their suspicious scores. For each of the resulting suspicious statements, we retrieve its statement type as well as the special priority associated with the type. The final suspicious score is the product of the SBFL suspicious score and the priority assigned to the statement type. We evaluate the proposed approach on widely used benchmark Defects4J [15]. Our evaluation results suggest that the proposed approach significantly outperforms the widely used SBFL techniques. It significantly reduces the absolute wasted effort (AWE) on five out of the seven programs, with an average reduction of 9.3% on all of the involved faulty programs.
The paper makes the following contributions: • A simple, intuitive, but accurate approach to fine-grained fault localization. To the best of our knowledge, it is the first statementlevel fault localization approach that leverages both dynamic and static information of the faulty programs. A significant advantage of the approach is that it is simple and intuitive, making it reliable, efficient, and easy to interpret/implement. • An extensive evaluation of the proposed approach on wellknown dataset (Defects4J). The evaluation results suggest that the proposed approach can significantly improve the state of the art in fine-grained fault localization.

RELATED WORK 2.1 Fine-grained Fault Localization
Spectrum-based fault localization (SBFL) [2,14,25] is one of the most widely used techniques that could be employed to locate both fine-grained and coarse-grained faulty source code [9,39]. Spectrums refer to the program execution traces of successful and failed executions, i.e., run-time profiles about which program entities are covered by each test. The key idea of spectrum-based fault localization is that a program entity covered by more failing tests but less passing tests is more likely to be faulty. To this end, SBFL techniques run test cases and generate spectrums based on the executions. Based on the resulting spectrums, SBFL techniques can leverage different formulae to estimate the suspicious scores for all software entities covered by failed executions. For example, Tarantula [14] computes suspicious scores as follows: where ( ) is the suspicious score of element , is the number of passed tests covering element , is the number of failed tests covering element , is the number of passed tests that do not cover , is the number of failed tests that do not cover . Chen et.al [5] compute the suspicious score based on similarity as follows: Abreu et.al [2] compute the suspicious score as follows: Wong et.al [37] compute the suspicious score as follows: where * is a parameter whose value should be no less than 1. Mutation-based fault localization (MBFL) [24,26,28] is another way to both fine-grained and coarse-grained fault localization. To the best of our knowledge, the approach proposed by Papadakis and Traon [27] is the first MBFL technique. It predefines mutation operators to generate mutants on specific code elements within a faulty program. It then runs test cases on the generated mutants, and utilizes Ochiai [2] formula to compute suspicious scores based on the executions of test cases. The rationale of MBFL is that mutation on faulty code elements is more likely to make passed tests fail while mutation on correct elements is more likely to make failed tests pass.
State-based fault localization [44,48] identifies suspicious statements by intentionally updating states of the faulty system while executing failed test cases. For example, during the execution of a failed test case, delta debugging [44] replaces the value of a variable with its corresponding value in passed test cases. If the replacement leads to the same fault, the variable is likely bug-free. Otherwise, the variable is suspicious. Predicate switching [34,48] is another well-known state-based fault localization technique. It switches a predicate executed by failed test cases. If the switch passes the failed test cases, the modified predicate is suspicious.
The fault localization approach proposed by Liblit et al. [21] computes suspiciousness of a predicate by estimating two conditional probabilities: the rate of being covered implies failed execution (noted as 1 ), and the rate of being true implies failed execution (noted as 2 ). If 2 is significantly greater than 1 , the predicate is likely to be faulty. Similarly, SOBER [4] computes suspiciousness of a predicate by calculating times of the predicate being true divided by times of the predicate being covered with regard to the execution of passed/failed test cases: where is the number of failed test cases covering predicate , and is the number of passed test cases covering predicate . Subscripts and represent the value of when associated test cases are executed. If ( ) and ( ) are significantly different, the predicate is considered to be suspicious. CBT [38] extends such approach to cover additional entities, e.g., statements and methods.
Our approach is similar to such approaches in that all of them could be employed for fine-grained fault localization. Our approach differs from them in that our approach leverages both dynamic test case execution and static statement types of the source code whereas none of such related approaches leverages any static information of the source code, e.g., statement types.

Coarse-grained Fault Localization
Coarse-grained fault location is to identify coarse-grained suspicious software entities, e.g., methods and classes. As mentioned in the preceding section, spectrum-based fault localization (SBFL) [2,6] [24,26,27,46] work on both coarse-grained and fine-grained software entities, varying from statements to modules. Besides such generic fault localization approaches, some approaches are specially designed for coarsegrained fault localization. For example, information retrieval (IR) based fault location [31,50] ranks potentially faulty elements (methods or classes) by computing their lexical similarity with bug reports. BLUiR [32], proposed by R.K.Saha, parses source file and extracts identifiers as well as code structure information. Based on such information, it leverages IR techniques to compute the similarity between source code and bug reports.
Learn-to-rank models are recently employed for fault location [19,20,49]. TraPT [20] leverages both SBFL and MBFL scores, and employs SVM to learn how to rank suspicious software entities by SBFL and MBFL scores. DeepFL [19] leverages both dynamic information (SBFL and MBFL scores) and static information, e.g., code complexity and the text of failed test cases. Based on such hybrid information, DeepFL employs deep learning techniques to learn how to rank suspicious software entities.
ProFL [22] is the first to leverage automated program repair (APR) for fault localization. It employs a mutation-based APR technique, called PraPR [10], to generate patches for each program element. Among such patches, it identifies high quality patches that pass more test cases. Software entities that are mutated to create high quality patches are considered as more suspicious entities.

Empirical Study on Fault Localization
Qi et.al [30] conducted an empirical study on the effectiveness of various fault localization techniques with regard to automated program repair. Their results suggest that [5] frequently outperform other SBFL variants. The results also suggest that accurate fault localization could reduce the number of candidate patches generated and validated by ARP tools, and thus improves their efficiency. Yang et.al [43] conducted an empirical study and found that suspiciousness-first techniques outperform rank-first techniques in both patch diversity and parallelity of program repair. Tung et.al [8] conducted an empirical study on enhancing IR-based fault localization techniques with coverage and code slicing information. Their results suggest that both coverage and code slicing information could improve the performance of IR-based fault localization techniques. S.Khatiwada et.al [16] conducted an empirical study whose results suggest that combining these orthogonal IR techniques targeting different aspects of similarity could enhance the confidence in results and helps to retrieve links that are missed by individual techniques. Jiang et.al [12] conducted a systematic analysis on different combinations of spectrum-based fault localization techniques and dynamic debugging techniques. Their results suggest that the combinations are often effective.
One of the common findings of such empirical studies is that hybrid approaches leveraging various orthogonal but complementary information are promising. Our approach is in line with this finding. To the best of our knowledge, it is the first hybrid approach to statement-level fault localization, leveraging both test case executions and static statement types. Figure 1 presents the overview of the proposed approach (HybridAFL). It is composed of two parts: offline analysis and online fault localization. The former analyzes large defect repositories, identifies significantly more/less error-prone statement types, and assigns special priorities to them. Based on the resulting priorities, the latter collects suspicious statements in a faulty program, computes suspicious scores for each of them, and ranks such statements. Overall, HybridAFL works as follows:

APPROACH 3.1 Overview
• HybridAFL applies statistics analysis to a fault repository to compute the error-proneness for each of the statement types involved in the repository. • Based on the resulting error-proneness, HybridAFL identifies special statement types that are steadily more/less error-prone than others. • HybridAFL assigns priorities to special statement types selected in the preceding step. The more error-prone a statement type is, the greater priority it receives. • For a faulty program to be debugged, HybridAFL collects suspicious statements from the faulty program and computes their suspicious scores by traditional SBFL. • HybridAFL adjusts the suspicious scores according to statement types, i.e., multiplying the SBFL suspicious scores by the priorities assigned to the statement types.
• All of the suspicious statements are ranked by the updated suspicious scores in descending order. Statements on the top are more likely to be faulty and thus should be inspected first. Notably, the offline analysis could be done once an for all whereas the online fault localization should be conducted independently on each of the faulty programs where faulty statements should be located. Details of the key steps are presented in the following sections.

Statistics-based Analysis on Fault Repositories
The key rationale of the proposed approach is that different types of statements are not equally error-prone. Some of them could be significantly more error-prone than others, and thus they should be given greater priorities during fault localization. To allocate quantitative priorities to different statement types, we apply statistics-based analysis to a given fault repository (noted as ) containing a set of faulty programs: where is the -th faulty program, and is the size of the repository. Each program ∈ is associated with a set of faulty versions. Each version of the faulty program is accompanied by a concise patch and one or more triggering test cases. Based on the triggering test cases, we collect all suspicious statements in -th version ( , ) of program : Statements covered by any of the triggering test cases are suspicious. The resulting suspicious statements are noted as ( , ). We can also identify all faulty statements in the faulty version, i.e., all statements deleted or modified by the associated patch. The resulting faulty statements are noted as ( , ). All suspicious statements associated with program are noted as ( ): where ( ) is the total number of faulty versions of program . All faulty statements associated with program are noted as ( ): The average possibility for a suspicious statement to be faulty is: We further divide the suspicious/faulty statements according to their statement types, i.e., all suspicious/faulty statements of the same type are classified into the same category: where is the total number of statement types.
( , ) and ( , ) are the suspicious/faulty statements of type . For a suspicious statement of type , its possibility of being faulty is noted as ( , ):

Assigning Priorities to Special Statements
The proposed approach is built on the assumption that some types of suspicious statements are significantly more/less error-prone than others. In this section, we specify how we identify such statements, and how we assign priorities to them in ranking suspicious statements.
For each type of the suspicious statements in program , we define its relative error-proneness as follows: where ( ) (as defined in Equation 10) is the average errorproneness for suspicious statements in program , and ( , ) (as defined in Equation 13) is the error-proneness for statement type . If ( , ) is significantly greater/smaller than 1, statements of type are significantly more/less error-prone than others, and thus should be given different priorities in fault localization. For a given statement type , we validate whether it deserves special priority as follows: (1) First, we compute its relative error-proneness over programs as: where is the number of programs. (2) Second, we normalize ( ) as follows: The normalization is applied to balance the magnification factors and minification factors. For example, ( 1 , ) = 2 suggests that the error-proneness of the statement type is twice of the average, and ( 2 , ) = 0.5 suggests that the error-proneness of the statement type is half of the average. In both cases, the magnification/minification factor of the relative error-proneness is 2. However, the absolute values of the relative error-proneness (i.e., 2 and 0.5 for the preceding example) are significantly different. To this end, we apply the preprocess, and the resulting values ( (2) = 0.3 and (0.5) = −0.3) share the same absolute value. (3) Statement type deserves a special priority if its relative error-proneness _ ( ) is steadily greater/smaller than the average. As a quantitative condition, statement type deserves a special priority if and only if at least 95% of the elements in _ ( ) are on the same side of zero (greater or smaller than zero). In other words, for a new faulty program, we can guarantee that statements of type on this program is more/less error-prone than the average with a high confidence coefficent of 95%. (4) If deserves special priority, we assign the priority as follows: where is the average of _ ( ), and −1 is the inverse function of .
( ) is greater than 1 if _ ( ) is steadily greater than the average, and ( ) is between 0 and 1 if _ ( ) is steadily smaller than the average. Notably, for statement types that do not deserve special priorities, we assign them the default priority, i.e., 1.

Hybrid Ranking
The proposed approach is hybrid in that it leverages traditional SBFL algorithms to compute the initial suspicious scores and then adjusts such scores according to statement types. For a faulty program ′ that are accompanied with passed test cases and failed test cases, we collect all suspicious statements that are covered by at least one failed test case. Such suspicious statements are noted as ( ′ ) (as defined in Equation 8). For each of the suspicious statements (noted as ), we leverage ℎ [2] to compute its initial suspicious score (noted as ( )) according to Equation 3. Ochiai is selected because it is one of the most widely used spectrum-based fault localization (SBFL) algorithms, and existing studies [9] suggest that it frequently outperforms other SBFL variants.
We further adjust the SBFL scores according to statement types as follows: where ( ) is the type of statement , and ( ( )) is the priority associated with the statement type ( ). All suspicious statements are ranked by the updated suspicious scores in descending order, and developers can inspect them in order.

EVALUATION 4.1 Research Questions
The evaluation investigates the following research questions: • RQ1: Are different types of statements equally error-prone?
If not, which kinds of statements are significantly more/less error-prone than others?

Dataset
The evaluation is based on the widely used Defects4J [15]. We select this dataset because it contains manually validated concise patches. It is critical that the patches are concise because concise patches are indispensable in the identification of faulty statements in subject programs (as explained in Section 3.2), and the identified faulty statements should serve as the ground truth of the evaluation. Patches in some defect repositories, like iBUGS [7] and ManyBugs [18], are often not concise, i.e., they often contain bug-irrelevant changes. Consequently, bug-free statements modified for bug-irrelevant reasons (e.g., refactoring or requirements changes) could be incorrectly identified as faulty statements, which may result in inaccurate ground truth for the evaluation. We exclude faulty versions whose patches do not remove or change any statements in the original faulty versions, i.e., such patches do nothing but insert new statements. We exclude such faulty versions because none of the involved statements are faulty according to the definition in Section 3.2. Notably, we also exclude such projects that contain less than 30 defects. As specified in Section 3.2, the proposed approach identifies special statement types according to their relative error-proneness on different projects. If the involved projects contain only a small number of defects, the relative error-proneness on such projects has high degree of randomness, which could significantly influence the evaluation results.
The resulting data set is composed of seven faulty projects containing 376 defects. Details are presented on Table 1.

Experiment Design
4.3.1 RQ1: Assumption: RQ1 concerns the assumption taken by HybridAFL, i.e., different types of statements are not equally errorprone. To answer RQ1, we compute the average error-proneness for each type of statements on the selected faulty projects (as specified in Section 4.2). We also analyze the variation of the error-proneness among faulty projects by comparing their ranges, averages, and medians. To visualize the difference, we draw a box-plot to illustrate how often special statements are more/less error-prone than others.

RQ2: Performance: RQ2 concerns the performance of
HybridAFL. To answer Rq2, we compare it against the widely used SBFL algorithm Ochiai [2]. It is selected for comparison because of the following reasons. First, it represents the state of the art, and is widely employed in automated program repair [10,13]. Second, it We apply HybridAFL and Ochiai to the selected dataset independently, and compute their performance, i.e., absolute waste effort (AWE) [47]. Given a faulty program and a ranked list of statements, AWE equals the ranking number (position) of the faulty statement. AWE is selected because it accurately represents the amount of effort wasted by automated program repair tools in generating invalid patches because of inaccurate fault localization.
Notably, the evaluation follows the widely used taken-one-out pattern. On each fold of the evaluation, a single project of the selected dataset is taken as testing data whereas other projects are taken as training data. Each of the projects is taken as testing data for once.

RQ3: Strength and Weakness
: RQ3 concerns the strength and weakness of HybridAFL. Because HybridAFL gives different priorities to different types of statements, it is likely that it is good at locating some kinds of statements (receiving highter priorities) whereas poor at locating other statements. To answer this question, we classify faulty statements in the selected dataset according to statement types, and compute how efficient HybridAFL is in locating such faulty statements.

RQ4: Selection of Special Statement Types:
The key idea of the proposed approach is to assign special priorities to such types of statements that are steadily more/less error-prone than the average. To this end, in Section 3.3 we identify such statement types according to their relative error-proneness, and compute priorities for each of them. Other statement types that are not selected receive the default priority (i.e.,1). To validate the necessity of the selection, we disable the selection, i.e., assigning priorities to all statement types according to Equation 17, and repeat the evaluation.

RQ5
: Median vs. Average: RQ5 concerns how the errorproneness of a given statement type should be computed from a corpus of faulty projects. In Section 3 (Equation 17), we take the average (arithmetic mean) of the error-proneness on different projects as the final value. An alternative approach is to take the median value. To this end, we replace the average in Equation 17 with the median, and repeat the evaluation as specified in Section 4.3.2.

RQ6
: Multi-level Sorting: RQ6 investigates whether multilevel sorting can further improve the performance of the proposed approach. Multi-level sorting [22] is to rank items according to an attribute (called first attribute) first and then leverage additional attributes (called secondary attributes) to further rank such items that are given equivalent priorities according to the first attribute. In our case, we may rank suspicious statements by SBFL scores first and then by error-proneness of statement types, or vice versa. RQ6 would investigate whether such multi-level sorting is a good alternative to the hybrid approach in Equation 19.

RQ7
: Effect on Other SBFL Algorithms: RQ7 investigates whether the key idea of the proposed approach (i.e., leveraging statement types to enhance state-of-the-art fine-grained fault localization algorithms) can be applied successfully to other SBFL algorithms. To answer this question, we replace Ochiai [2] in Equation 3 with Jaccard [5], [37] and [3], and repeat the evaluation as specified in Section 4.3.2. Such SBFL algorithms are selected because they are the most popular SBFL variants [9,37].

Results and Analysis
4.4.1 RQ1: Some Types of Statements are Significantly More Error-Prone Than Others: To answer RQ1, we compute the relative error-proneness (i.e., ( , ) in Equation 14) for each of the statement types on each of the subject programs. Notably, the relative error-proneness ( , ) indicates to what extent statements of type are more/less error-prone than others in the same project. We do not present/compare the absolute error-proneness because it varies significantly among faulty projects, heavily dependent on the absolute numbers of suspicious statements in the projects rather than statement types.
Results of the analysis are presented on Table 2. Notably, for space limitation Table 2 presents only popular statement types that account for at least 1% of the suspicious statements in the subject programs. All of the statement types on Table 2 together account for more than 97% of the suspicious statements. To visualize the different, we also present the relative error-proneness as a box-plot in Figure 2. The horizontal axis on the figure represents different statement types whereas the vertical axis represents the relative error-proneness of different types of statements. A box plot is constructed from five values: the minimum value, the first quartile, the median, the third quartile, and the maximum value. Notably, the enhanced for statements (called   From Table 2 and Figure 2, we make the following observations: • First, some statement types are significantly more error-prone than others. For example, the average relative error-proneness (1.47) of if statements is significantly higher than that (0.56) of for statements. • Second, some statement types are steadily more error-prone than the average. For example, if statement is more error-prone than the average on 6 out of the 7 projects. During fault localization, we should pay more attention to such kind of statements to speed fault localization. • Third, some statement types are steadily less error-prone than the average. For example, constructor invocation statements are never found faulty. Other statements, e.g., for and expression statements, are also steadily less error-prone than the average. We conclude based on the preceding analysis that different types of statements are not equally error-prone. Some kinds of statements, e.g., if statements, are significantly more error-prone than others whereas some kinds of statements, e.g., constructor invocation, for, and expression statements, are significantly less error-prone than others. The conclusion validates the assumption that serves as the basis of the proposed approach.

RQ2
: HybridAFL Improves the State of the Art: To answer RQ2, we apply the proposed approach (HybridAFL) and traditional SBFL (Ochiai) to the selected faulty projects independently. Results of the take-one-out (k-fold) evaluation are presented on Table 3. Absolute waste effort (AWE) represents how much effort has been wasted because of the inaccurate faulty localization. With regard to automated program repair (APR) that depends on the automated fault localization, AWE represents how many times APR tools have tried to fix a suspicious statement before they finally come to fix the faulty statement. Consequently, the smaller AWE is, the more efficient APR tools would be. The second row of Table 3 presents the performance (AWE) of Ochiai wheras the third row presents the performance of HybridAFL. The last row presents to what extent HybridAFL can reduce AWE with regard to the baseline approach Ochiai: positive percentages on the last row represent reduction in AWE whereas negative percentages represent increase in AWE.
From Table 3 we make the following observations: • First, HybridAFL significantly outperforms Ochiai. On 5 out of the 7 projects, HybridAFL results in smaller AWE than that of Ochiai. The reduction in AWE varies from 9.3% (on Closure) to 25.7% (on Lang). On average, the reduction of AWE on all of the involved subject projects is 9.3%. • Second, although the overall performance of HybridAFL is better than that of Ochiai, it is not guaranteed that HybridAFL can always outperform Ochiai. On 2 out of the 7 projects, i.e., JSoup and Databind, HybridAFL results in increased AWE. On Databind, HybridAFL increases AWE slightly by only 1.5%. However, on JSoup, it increases AWE significantly by 9.2%. The major reason for the increase is that the relative error-proneness of different statement types varies significantly from project to project. For example, on Jsoup, the relative error-proneness (0.7) of if statements is significantly smaller than that (1.6) on other projects. As a result, the priorities of statement types learned from other projects fail to work on Jsoup, which results in increased AWE. We conclude based on the preceding analysis that the proposed approach frequently outperform the state-of-the-art approach, and it successfully reduces absolute waste effort by 9.3% on average.

RQ3: Good at Locating High-Priority Statements:
To answer RQ3, we compute the performance of the proposed approach on each statement types. Evaluation results are presented on Table 4. Each column of the table presents the effect of the proposed approach in locating a specific type of faulty statements. The second row of the table presents the priorities assigned to different statement types (according to Equation 17 in Section 3). The third row presents how often the proposed approach locates the faulty statements more quickly than the baseline approach (SBFL) whereas the fourth row presents how often it locates the faulty statements less quickly than the baseline. The fifth row presents how often they draw a tie.
From Table 4, we make the following observations: • The proposed approach works well in locating faulty if statements. On 66 out of the 69 faulty if statements, the proposed approach outperforms the baseline, i.e., the faulty statements are ranked in the front of the positions suggested by the baseline approach. We also notice that on average the proposed approach reduces AWE by 32.7% on average in locating such faulty if statements. • The proposed approach has negative effect on less error-prone statement types, e.g., expression and for statements. Such statements are less error-prone, and thus are given lower priorities by the proposed approach. As a result, their suspicious scores are underestimated, and they are ranked in lower positions. • The proposed approach has minor positive effect on normal statement types that receive the default priority (i.e., 1). For example, on 50% of the variable declaration statements, the proposed approach outperforms the baseline whereas it loses   on only 36.7% of the cases. As a result, the proposed approach reduce AWE by 2.8% in locating variable declaration statements. The reason for the minor positive effect is that numerous less error-prone statements (especially expression statements) are ranked behind by the proposed approach, and thus such normal statements like variable declaration receive higher ranking. We conclude based on the preceding analysis that the proposed approach is good at locating more error-prone statement types whereas it could be less effective in locating less error-prone statement types. Notably, more error-prone statement types account for a larger proportion of faulty statements. For example, if statements alone account for more than 20% of the faulty statements in Defects4J [15].

RQ4: Selection of Special Statement
Types: To answer RQ4, we assign special priorities to all statement types discovered in the subject programs according to Equation 17, and repeat the evaluation. Evaluation results are presented on Table 5. The first column specifies the setting of the evaluation, i.e., whether we assign special priorities to selected statement types only (selection enabled) or assign priorities to all statement types (selection disabled). The other columns present the performance (AWE) of the proposed approach varying among different projects. The last row presents to what extent disabling the selection would decrease AWE .
From Table 5, we observe that the selection of special statement types is useful. Disabling the selection results in decreased performance (i.e., increased AWE) on 5 out of the 7 projects, and the average AWE on all projects is increased by 2.3%. The reason is that the relative error-proneness of some statement types (e.g., variable declaration) varies significantly among projects. For example, on four out of the seven projects variable declaration is more errorprone than the average whereas it is less error-prone than the average on the other three projects. As a result, assigning a universal priority to variable declaration could randomly result in negative/positive effect depending on the characters of involved faulty projects. Assigning priorities to special statement types only (that are steadily more/less error-prone than the average) helps to reduce the randomness, and thus improves the robustness of the proposed approach. . The other columns present the performance (AWE) of the proposed approach. The last row presents to what extent replacing the average with median can improve the performance (i.e., reducing AWE).
From Table 6, we observe that replacing the average with median cannot improve the performance. The replacement results in increased AWE on 6 out of the 7 projects, and the average AWE is also slightly increased. However, we also notice that the impact of the replacement is minor, and in most cases the performance changes slightly by no more than 3%.   From Table 8, we make the following observations: • First, the key idea improves all of the evaluated SBFL algorithms with regard to their performance. The improvement (i.e., reduction in AWE) varies slightly from 8.8% to 9.3%. • Second, the improvement depends more on projects than on SBFL variants. For example, the idea results in the greatest reduction in performance on project JSoup, regardless of the employed SBFL variants. We conclude based on the preceding analysis that the proposed key idea, i.e., assigning different priorities to different statement types in fault localization, could be applied to various SBFL variants. The application could result in significant improvement in performance, regardless of the employed SBFL variants.

Threats to Validity
A threat to construct validity is that the labels of faulty statements in the evaluation dataset could be incorrect, which may result in inaccurate calculation of the performance of the evaluated approaches. Notably, the employed dataset, i.e., Defects4J, does not explicitly specify faulty statements. To this end, we identify faulty statements by analyzing patches provided by Defects4J: Statements deleted or modified by the patches are faulty statements. However, it could be inaccurate when the patches are incomplete or unconcise. They could also be inaccurate when there are multiple valid patches for the same faulty program: Faulty statements identified according to different patches could be inconsistent. However, inaccurate identification of faulty statements could significantly influence the computation of the performance in fault localization.
A threat to external validity is that the involved dataset is small and thus the conclusions drawn on such dataset may not be generalized to other datasets (i.e., faulty programs to be fixed). The negative effect of the limited size is twofold. On one side, the limited number of faulty statements/programs leveraged to derive the priorities for different statement types makes the resulting priorities questionable with regard to its representativeness. On the other side, the limited number of faulty statements/programs leveraged as testing data reduces the conclusions' generalizability: The randomness of the results increases significantly with the decrease in the size of the testing data. To reduce the threat, we leverage the largest public defect repository (Defects4J) with manually validated concise patches. Notably, we do not leverage artificial-fault datasets where faults are injected manually or automatically by mutation tools. Such artificial faults could be significantly different from real faults, and thus they may have significantly different error probability.

Simple, Intuitive, and Lightweight
Simpleness is a big plus for the proposed approach. First, the approach is simple and intuitive, making it easy to understand, implement, and use. The proposed approach is essentially a slight adaption to the widely used SBFL algorithms. The key idea for the adaption, i.e., different types of statements are not equally error-prone, is intuitive. Second, because of the simpleness, the proposed approach could be integrated into various existing fault localization algorithms without complex adaption. For example, our evaluation results in Section 4 suggest that the proposed approach significantly improves all of the evaluated SBFL variants. The only required adaption is to time the resulting suspicious scores (from baseline approaches) by fixed priorities (Equation 19). In future, we will try to integrate it into other AFL techniques, e.g., mutation-based techniques and statebased techniques. Finally, the proposed approach itself, excluding the involved baseline algorithm (SBFL), is lightweight. Although it is time-consuming to determine the priorities of different statement types by analyzing a large corpus, it could be done offline and it is done once and for all. The online adaption depends on the types of suspicious statements only, and thus could be done efficiently. It is a significant advantage of the proposed approach compared to spectrum-based fault localization and mutation-based algorithms that require time/resource-consuming execution of test cases.

Lack of Large Defect Repositories
As specified in section 3, the proposed approach relies on defect repositories to derive priorities for special statement types. However, it is challenging to construct large repositories of real defects from the industry as well as concise patches (or explicitly specified faulty statements). To the best of our knowledge, Defects4J [15] is the largest one with less than one thousand real defects collected from open-source applications as well as their corresponding patches.
The limited size of the available qualified defects may reduce the representativeness of the resulting priorities assigned to various statement types, and thus limits the practicability of the proposed approach. Notably, generating artificial defects by mutation tools would not help. The error probability of such artificial defects may not follow the same model as real defects do, and thus they could not be employed to infer the error-proneness of real statements. Notably, even with the available repository (Defects4J) only, our approach significantly improves the state of the art.

Programming Language Specific Models
Although the proposed approach is generic, priorities derived from one programming language may not be directly applicable to other programming languages because of the following reasons. First, different programming languages may have different types of statements. For example, ℎ are common in modern programming languages like Java, but they are often illegal in traditional languages like C and C++. Consequently, priorities learned from C or C++ programs might not work for Java programs. Second, even the same statement type may follow different error probability models in different programming languages. Consequently, priorities derived from the error probability models could be language-specific as well.

CONCLUSIONS AND FUTURE WORK
Accurate fault localization is critical for program debugging and program repairing. However, it remains challenging to locate faulty statements accurately and automatically. Inaccurate fault localization often results in significant effort wasted in inspection of bug-free statements. To this end, in this paper, we propose a simple and intuitive approach to fine-grained automated fault localization. The key idea of the proposed approach is that different types of statements are not equally error-prone, and thus statement types should be exploited by statement-level fault localization. To the best of our knowledge, the proposed approach is the first hybrid approach to fine-grained fault localization that leverages both dynamic test case execution and static statement types. Our evaluation results on De-fects4J suggest that the proposed approach significantly outperforms the widely used fine-grained fault localization approaches. Our data and script are publicly available [? ].
In the future, it is interesting to construct large fault repositories and to derive error-proneness of different statement types based on the resulting repositories. As discussed in Section 5, existing repositories of real faults are rather small, which limits the practicability of the proposed approach. However, automated or semi-automated construction of large fault repositories remains challenging because of the following reasons. First, it is difficult to distinguish bug-fixing commits from other commits automatically. Second, it is difficult to automatically distinguish bug-fixing changes from other changes (e.g., refactoring) within the same bug-fixing commit. In future, it is also interesting to explore additional static or dynamic information that could be leveraged for statement-level fault localization. The proposed approach may inspire a series of hybrid approaches to fine-grained fault location that leverage different dynamic/static information.