Data Mining-Based Techniques for Software Fault Localization

LACODAM); Mireille Ducass\'e (DRUID); Olivier Ridoux (DRUID); Peggy Cellier (INSA Rennes; S\'ebastien Ferr\'e (LACODAM); W. Eric Wong

REVIEW 3 major objections 6 minor 27 references

Data Mining-Based Techniques for Software Fault Localization

T0 review · 3 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Mining execution traces with association rules and formal concept analysis reduces fault localization to inspecting the head concepts of a failure lattice.

desk verdict A clearly written survey chapter that recycles prior results and adds no new evidence; fine as an introduction, not as a research contribution. read the letter →

arxiv 2505.18216 v1 pith:CZFCW5JK submitted 2025-05-23 cs.SE cs.AI

Peggy Cellier (INSA Rennes , LACODAM) , Mireille Ducassé (DRUID) , Sébastien Ferré (LACODAM) , Olivier Ridoux (DRUID) , W. Eric Wong This is my paper · ORCID

classification cs.SEcs.AI

keywords faultlocalizationformalconceptanalysisassociationrulesfailurelatticeN-grammultiplefaultsGUItestingexecutiontraces

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The chapter claims that fault localization can be recast as a data-mining problem over execution traces: each test case is a transaction, executed lines (or GUI events) are items, and PASS/FAIL is the outcome attribute. Mining association rules of the form P → FAIL yields failure rules, and organizing those rules as a formal concept lattice yields a failure lattice in which the most informative explanations sit at the head concepts of support clusters. Because support climbs monotonically from bottom to top and lift falls monotonically inside each support cluster, a debugger can ignore every non-head explanation and inspect only a small fault context. The chapter argues this works for several faults at once: a bottom-up traversal tagging failure concepts as explained terminates with all failures explained when minimum support is 1 and the debugger correctly recognizes real faults. For programs whose behavior is order-sensitive, and for GUI applications whose test cases are event sequences, the same rule-mining idea is applied to N-grams of executed blocks or events.

What carries the argument

The central machinery is the failure lattice, a concept lattice built from the formal context whose objects are failure-rule premises and whose attributes are executed line numbers. Association rules of the form P → FAIL, with support measuring how many failed executions contain P and lift measuring attraction between P and failure, supply the explanations; formal concept analysis orders them. Two monotony theorems carry the search: support increases globally when moving bottom-up, and lift decreases within each support cluster, so only the head concept of each cluster can be the best explanation. Failure concepts—maximally specific concepts whose intents are contained in a failed execution—let the multi-fault traversal decide when a branch is fully explained. In the N-gram variant, linear execution blocks (directed paths in the execution-sequence graph whose vertices have indegree 0 or 1) are the items, so an N-gram captures N−1 branches, and confidence ranks the blocks, then lines, for the debugger.

What would settle it

Take a program whose only fault is a branch condition written i > 1 instead of i > 0 and a test suite containing inputs i = 0, i = 1, and i = 2; the faulty line is executed in every failing and every passing trace, so no P → FAIL rule has a premise that isolates it, and if the failure-lattice head concepts omit the line the method's ranking claim is refuted on that input.

Watch

Extended reading notes

Core claim

The central discovery is that the set of all failure rules P → FAIL, viewed through formal concept analysis, forms a failure lattice whose geometry encodes the debugging search. The trace context records, for each test case, which lines were executed and whether the test passed or failed. Association rules with conclusion FAIL are explanations; the failure lattice is built from their premises. In that lattice the most specific explanations are at the bottom, and explanations that cover the same set of failing executions form support clusters. Each support cluster has a unique head concept, the explanation with the largest extent and highest lift; local monotony of lift means the other members of the cluster are dominated and need not be examined. Failure concepts—maximally specific concepts whose line sets are contained in some failed execution—are the best approximations of failed executions, and exploring the lattice bottom-up while asking a competent debugger to confirm hints accumulates a small fault context and stops only when all failure concepts are explained. In the four-fault Trityp example, this traversal found all four faults after the debugger inspected nine lines. For order-dependent failures, N-gram analysis over linear execution blocks (or over GUI event sequences) ranks statements or event handlers by the confidence that a test containing the N-gram fails, with the block representation making each N-gram correspond to N−1 branches.

Load-bearing premise

The load-bearing premise is that a fault shows up distinctly enough in which lines or events get executed by failing tests, so the faulty line outranks innocent lines, even though the chapter concedes that faulty lines can run without failing and correct lines in the same basic block as a fault can look equally suspicious.

Editorial extensions

If this is right

If the failure lattice is correct, a debugger need only inspect head concepts of support clusters; in the worked Trityp example four faults were located after inspecting nine lines.
Minimum support acts as a resolution cursor: high thresholds surface the most visible faults cheaply, and lowering the threshold zooms into rarer faults, so a global debugging process can start coarse and refine.
For multiple faults, dependencies between faults appear as structural relations among failure concepts (independent faults in disjoint branches, loosely dependent faults sharing subconcepts, strongly dependent faults in nested support clusters), so one traversal can explain all failures without rescanning the lattice.
Total-order rankers such as single-line spectrum methods lose the links between lines; the lattice restores those links, so order-sensitive faults and faults that are only visible in multi-line premises are not missed.
In N-gram analysis, because each block N-gram encodes N−1 branches, small values of N (2 or 3) suffice to capture the path differences that distinguish failing traces, and the same confidence ranking transfers to GUI event handlers.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper uses line numbers as attributes, but the failure-lattice construction is attribute-agnostic; replacing lines with variable states or data-flow edges could localize data-driven faults, a testable extension the chapter only gestures at.
The resolution-cursor analogy suggests an automated schedule: run the lattice once at high support, then progressively lower minimum support only in support clusters that still contain unexplained failure concepts, rather than rebuilding the whole lattice.
The chapter's explicit approximation—the failure lattice describes failure rules exactly but failed executions only approximately—could be quantified by measuring how well each failure concept's intent matches the traces of its support cluster; that would give a principled stop criterion beyond 'all failure concepts explained'.
For GUI testing, ranking event handlers rather than events could be refined by treating handlers as shared items across multiple events, since one handler can respond to several events; this would directly connect the N-gram ranking to code-level localization.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

This is a book chapter, not a research paper, and the honest thing to say up front is that there is no new science in it. Sections 7.4–7.5 are drawn from the authors' dissertation and paper, 7.7 from Nessa et al., and 7.8 from Yu et al. The only new-looking part is the chapter organization. The extracted text is visibly garbled (broken references, CDEF placeholders), so I would not hold that against the authors, but it does mean the arXiv version is not camera-ready.

What the chapter does well is exposition. The failure-rule formalization, the failure lattice, and the traversal algorithm for multiple faults are explained clearly, with a worked Trityp example. The distinction between support clusters and head concepts, and the argument that lift is only locally monotone within a support cluster, is a genuinely useful way to think about fault localization. For someone new to FCA/AR methods in debugging, this is a readable entry point.

The soft spots are real but mostly known to the authors. The effectiveness claims are not supported in the chapter; the comparisons are deferred to another section. The theorems on monotony are cited, not proved. And the method, as presented, abstracts traces to line sets. The stress-test note is on target: the failure lattice ignores execution order, so order-dependent faults (swapped statements, missing reset) can be invisible to the head-concept ranking. The chapter itself concedes this is why N-gram analysis is needed, but the FCA part is sold as a general approach without a bound on the fault class where coverage is sufficient. A careful referee would ask for that characterization.

The citation pattern is self-referential but not abusive; the prior work is the source of the technical content, so the self-citations are accurate. There is no code or data shipped, but this is a survey chapter.

Bottom line: if the goal is a research claim, this does not stand alone. If the goal is a teaching or reference chapter in a software debugging volume, it is serviceable, provided the production issues (garbled text, broken references) are fixed. I would not send it to a research venue as a new contribution; I would accept it as a chapter after light revision.

Referee Report

3 major / 6 minor

Summary. This chapter presents symbolic data-mining methods for software fault localization. It introduces a trace context in which test executions are objects and executed program lines are attributes, derives failure rules of the form P→FAIL with support, confidence, and lift, and uses formal concept analysis to organize these rules into a failure lattice. It then proposes a bottom-up traversal of this lattice to locate one or several faults, with a worked Trityp example, and extends the approach using N-gram analysis over execution blocks and GUI event sequences. The manuscript is largely expository: formal definitions and lemmas are given, but empirical comparisons and evaluations are referenced rather than presented inside the chapter.

Significance. The chapter has several strengths: it gives a careful formal treatment of the trace context and failure rules, provides a worked multiple-fault example on the Trityp program, defines a useful taxonomy of fault dependencies (ID, LD, SD, MSD), and proposes an explicit lattice-traversal algorithm with a stopping criterion. If the claims were supported by the data and the limitations properly scoped, the failure-lattice navigation would be a valuable expository synthesis of association-rule and FCA-based debugging. As it stands, the central effectiveness claims are supported only by informal reasoning and by references to the authors' prior work, and the coverage-based abstraction is acknowledged but not bounded; the chapter would need considerably more evidence to substantiate a practical fault-localization result.

major comments (3)

[§7.4.1] The trace context used for failure rules records only executed line numbers, and the text explicitly states that "the order of the attributes in a formal context does not matter, this forms an abstraction of a standard trace" (paragraph after Lemma 3). Because of this abstraction, a fault whose effect depends on execution order rather than coverage — such as swapped statements, a missing reset that leaves the same lines executed, or a use-after-free triggered by a different call order — can produce identical line sets in passing and failing executions. Such a fault cannot be singled out by a head concept of any support cluster, yet the claim in §7.5.1 that the fault context is a small program part to inspect is made without restricting the fault class. Section 7.7 acknowledges that "in most cases, the failure is dependent on the sequence of execution", but §§7.4–7.6 do not feed sequence information into the failure lattice; the manuscript needs an explicit statement of the fault classes for which line-coverage rules are sufficient, or a bound on the frequency of the exceptions listed in §7.4.
[§7.5.1] Algorithm 7.1's termination claim — "The competent debugger hypothesis ensures that CfailuretoExplain ends at empty when min sup is equal to 1" — rests on an unformalized oracle. The manuscript also concedes in §7.4 that executing a faulty line need not cause a failure and that absolutely correct lines can appear to cause failure, but it gives no frequency bounds for these exceptions. As a result, the key efficiency claim that only head concepts and a small fault context need be inspected is not established: with a less-than-competent oracle, or if those exceptions are common, the algorithm explores all concepts, which is precisely the worst case the method is intended to avoid. A formal characterization of the oracle's required competence and of the fault-coverage conditions would be needed to support the claimed reduction in debugging effort.
[§7.6] The chapter repeatedly claims superiority over other fault-localization methods, but no comparison data are included in the manuscript. §7.5.1 refers to "Section 1.6 for comparative experiments", and §7.6 says "we show" improvements relative to Renieris and Reiss, Cleve and Zeller, and Jones et al., yet no such section, table, or experimental result appears anywhere in the chapter. Likewise, the statement in §7.4.2 that "experiments show that acceptable minimum support is quite low" is unsupported here. Since the central claims are about practical debugging effectiveness, the supporting evidence needs to be either included or the claims explicitly scoped as illustrative rather than comparative.

minor comments (6)

[Abstract] The sentence "In their original inception, they both consider data in the form of an object-attribute table." is repeated verbatim twice.
[Table 7.1] The Trityp code listing contains several typos: "Public int Trityp()" should presumably be "public int Trityp()", "coversiontrityp" and "scalen" are misspelled, and "triyp" is used inconsistently with "trityp" in lines 62 and 87. Since this listing is the running example, it should be corrected.
[Cross-references] Several cross-references are broken: "Figure 8.3" should be Figure 7.2, "Chapter 8.5" should likely be Section 7.5, "Section 1.3" should be Section 7.3, and two bibliography entries contain the placeholder "Erreur ! Source du renvoi introuvable."
[Table 7.5] Table 7.5 is corrupted in places: the caption reads "with minand min" without the missing parameter names and values, rule identifiers appear as "1r2r8r9r", and the column labels are unclear; the table needs a clean reconstruction.
[§7.7.5] The concluding sentence of Section 7.7.5 is grammatically incomplete: "The augmenting the execution traces with data flows in order to pinpoint data-driven faults is worth investigating." appears to be missing a subject or verb and should be rewritten.
[§7.8.3] In the explanation of Algorithm 7.4, the placeholders "CDEF" and "CH-grams" appear where "NMAX" and "N-grams" are intended; these should be replaced throughout the paragraph.

Circularity Check

1 steps flagged · score 4.0 of 10

Head-concept reduction rests on monotonicity theorems cited to the authors' own prior paper; no definitional prediction loop found elsewhere.

self citation load bearing [Section 7.4.2 (Failure Lattice), after Lemma 4]
"Support increases when going upstream, from bottom to top. We call this the global monotony of support ordering. This is a theorem [[5]]. ... More generally, lift decreases when going bottom-up in a support cluster. We call this behavior the local monotony of lift ordering, and it is also a theorem [[5]]. ... It is useless to investigate explanations other than the head concepts."

The step that reduces debugging effort to head concepts is load-bearing: it is what lets the method present only a few concepts to the debugging oracle. Its sole stated justification is two theorems cited to [5], a paper authored by all four chapter authors. The chapter does not prove these theorems or re-derive them from the FCA definitions in Section 7.3, and it reproduces no independent data in this chapter to confirm the head-concept reduction. Thus the 'only inspect head concepts' procedure is carried by a self-citation chain rather than by an argument internal to the chapter. This is not a definitional tautology, but it is a self-citation load-bearing premise.

full rationale

The chapter is a tutorial exposition of the authors' own data-mining fault-localization methods; large parts are explicitly 'Part of Chapter 7.x is from Reference [6]', the authors' PhD dissertation. The formal machinery (failure rules, failure context, failure lattice) is defined directly from the trace context, so the statement that the failure lattice 'describes exactly the selected failure rules' is true by construction rather than a prediction. No parameter is fitted to a subset of data and then reported as a prediction; minsup and minlift are user-set resolution cursors, and the N-gram and GUI variants are rankings of N-grams by confidence. The main circularity-adjacent element is the reliance of the head-concept reduction on theorems cited to the authors' own [5]; this is scored as some self-citation with independent content because the underlying monotonicity facts are mathematical and the rest of the pipeline (FCA, AR, N-gram) uses standard external methods. The absence of reproduced experiments is a verification gap, not circularity.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

The ledger lists the hand-tuned thresholds and domain assumptions that the presented methods rely on. No new physical or formal entities are introduced here; the failure lattice, failure concepts, and linear execution blocks are carried over from prior publications and are internal constructs rather than independently evidenced entities.

free parameters (3)

min_support (minsup) = varies: 90% in §7.7.4; 1..|extent(FAIL)| in §7.4.2
Hand-chosen threshold that controls which N-grams or failure rules survive; changing it changes the localized lines, and the chapter gives experience-based advice rather than a data-driven selection.
NMAX (max N-gram length) = 2 or 3 for programs; 3 for GUI
User-set parameter in Algorithms 7.2 and 7.4; determines the length of subsequences and therefore the set of candidates examined.
min_lift = 1 in the worked example of Figure 7.6
Acts as a zoom on support clusters in §7.4.2; the choice affects which failure rules are eliminated and how the lattice is explored.

assumptions (5)

domain assumption The attributes recorded in the trace context are line numbers of executed statements, and this abstraction is sufficient for fault localization.
Section 7.4 states 'we assume that the attributes recorded in the trace context are line numbers of executed statements.'
domain assumption A competent debugging oracle can locate a fault from the clues provided by a failure concept.
Algorithm 7.1 and §7.5.1: 'The competent debugging hypothesis ensures that CfailuretoExplain ends at empty when min sup is equal to 1.'
domain assumption A failing execution shares a distinctive sequence of statements or events that is uncommon in passing executions.
Section 7.7.4: 'a specific sequence or path of execution will cause the program to fail, and this sequence will be very common in the failing traces but not so common in the passing traces.'
standard math Fundamental theorem of formal concept analysis: formal concepts of a context form a complete lattice, with the stated closure properties of extent and intent.
Invoked in §7.3.1, Theorem 1 and Lemma 1, as standard FCA background.
domain assumption The four fault-dependency classes (ID, LD, SD, MSD) cover all pairs of faults and have the stated consequences for the failure lattice.
Definition 7 and Lemmas 6-9 in §7.5.1 assert that these relations are exhaustive and that they produce the claimed lattice signatures.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Data Mining-Based Techniques for Software Fault Localization." pith.science (2026). https://pith.science/paper/CZFCW5JK

@misc{pith2026250518216,
  author       = {Pith},
  title        = {Pith review of: Data Mining-Based Techniques for Software Fault Localization},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CZFCW5JK}},
  note         = {Machine review of arXiv:2505.18216}
}

read the original abstract

This chapter illustrates the basic concepts of fault localization using a data mining technique. It utilizes the Trityp program to illustrate the general method. Formal concept analysis and association rule are two well-known methods for symbolic data mining. In their original inception, they both consider data in the form of an object-attribute table. In their original inception, they both consider data in the form of an object-attribute table. The chapter considers a debugging process in which a program is tested against different test cases. Two attributes, PASS and FAIL, represent the issue of the test case. The chapter extends the analysis of data mining for fault localization for the multiple fault situations. It addresses how data mining can be further applied to fault localization for GUI components. Unlike traditional software, GUI test cases are usually event sequences, and each individual event has a unique corresponding event handler.

Figures

Figures reproduced from arXiv: 2505.18216 by the authors.

**Figure 7.** [PITH_FULL_IMAGE:figures/full_fig_p005_7.png] view at source ↗

**Figure 8.** ) [PITH_FULL_IMAGE:figures/full_fig_p010_8.png] view at source ↗

Figures from the paper (9 more)

**Figure 7.** Figure 7 [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]

**Figure 7.** Figure 7 [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]

**Figure 7.** Figure 7 [PITH_FULL_IMAGE:figures/full_fig_p012_7.png]

**Figure 7.** Figure 7 [PITH_FULL_IMAGE:figures/full_fig_p015_7.png]

**Figure 7.** Figure 7 [PITH_FULL_IMAGE:figures/full_fig_p020_7.png]

**Figure 7.** Figure 7 [PITH_FULL_IMAGE:figures/full_fig_p021_7.png]

**Figure 7.** Figure 7 [PITH_FULL_IMAGE:figures/full_fig_p023_7.png]

**Figure 7.** Figure 7 [PITH_FULL_IMAGE:figures/full_fig_p024_7.png]

**Figure 7.** Figure 7 [PITH_FULL_IMAGE:figures/full_fig_p028_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

27 extracted references · 21 canonical work pages

[2]

ISBN 1-55860-153-8

Morgan Kaufmann Publishers Inc. ISBN 1-55860-153-8. URL http://dl.acm.org/citation.cfm?id=645920.672836

work page arXiv
[3]

Agrawal, T

R. Agrawal, T. Imielin´ski, and A. Swami. Mining association rules between sets of items in large databases. In Proceedings of the 1993 ACM SIGMOD International Conference on Management of Data (SIGMOD ’93), pages 207–216, New York, NY, USA,

work page 1993
[4]

S. Brin, R. Motwani, J. D. Ullman, and S. Tsur. Dynamic Item-set Counting and Implication Rules for Market Basket Data. In Proceedings of the 1997 ACM SIGMOD International Conference on Management of Data (SIGMOD ’97), pages 255–264, New York, NY, USA,

work page 1997
[8]

Dallmeier, C

V. Dallmeier, C. Lindig, and A. Zeller. Lightweight Defect Localization for Java. In Andrew P. Black, editor, ECOOP 2005 - Object-Oriented Programming, pages 528–550, Berlin, Heidelberg,

work page 2005
[10]

ISBN 1-58113-993-4

ACM. ISBN 1-58113-993-4. doi: 10.1145/1101908.1101979. URL http://doi.acm.org/10.1145/1101908.1101979

arXiv
[15]

J. A. Jones, M. J. Harrold, and J. Stasko. Visualization of Test Information to Assist Fault Localization. In Proceedings of the 24th International Conference on Software Engineering (ICSE 2002), pages 467–477, May

work page 2002
[16]

J. A. Jones, J. F. Bowring, and M. J. Harrold. Debugging in Parallel. In Proceedings of the 2007 International Symposium on Software Testing and Analysis (ISSTA ’07), pages 16–26, New York, NY, USA,

work page 2007
[17]

ISBN 978-1-59593-734-6

ACM. ISBN 978-1-59593-734-6. doi: 10.1145/1273463.1273468. URL http://doi.acm.org/10.1145/1273463.1273468

arXiv

Show all 27 references

[18]

doi: 10.1109/QSIC.2005.45

2005 doi
[19]

Liblit, M

B. Liblit, M. Naik, A. X. Zheng, A. Aiken, and M. I. Jordan. Scalable Statistical Bug Isolation. In Proceedings of the 2005 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI ’05), pages 15–26, New York, NY, USA,

2005
[20]

ISBN 1-59593-056-6

ACM. ISBN 1-59593-056-6. doi: 10.1145/1065010.1065014. URL http://doi.acm.org/10.1145/1065010.1065014
[21]

doi: 10.1109/TSE.2005.117

ISSN 0098-5589. doi: 10.1109/TSE.2005.117

2005 doi
[27]

ISBN 1-59593-383-2

ACM. ISBN 1-59593-383-2. doi: 10.1145/1143844.1143983. URL http://doi.acm.org/10.1145/1143844.1143983
[30]

Z. Yu, H. Hu, C. Bai, K. Cai, and W. E. Wong. GUI Software Fault Localization Using N-gram Analysis. In 2011 IEEE 13th International Symposium on High-Assurance Systems Engineering, pages 325–332, Nov

2011
[31]

Zhao and K

L. Zhao and K. Cai. Event Handler-Based Coverage for GUI Testing. In 2010 10th International Conference on Quality Software, pages 326–331, July

2010
[1978]

doi: 10.1109/C-M.1978.218136

ISSN 0018-9162. doi: 10.1109/C-M.1978.218136

1978
[1993]

ISBN 0-89791-592-5

ACM. ISBN 0-89791-592-5. doi: 10.1145/170035.170072. URL http://doi.acm.org/10.1145/170035.170072
[1994]

ISBN 0-89791-636-0

ACM. ISBN 0-89791-636-0. doi: 10.1145/174675.175935. URL http://doi.acm.org/10.1145/174675.175935
[1997]

ISBN 0-89791-911-4

ACM. ISBN 0-89791-911-4. doi: 10.1145/253260.253325. URL http://doi.acm.org/10.1145 /253260.253325
[2002]

doi: 10.1145/581396.581397
[2003]

doi: 10.1109/ ASE.2003.1240292

2003 arXiv
[2004]

doi: https://doi.org/10.1016/S0306- 4573(03)00018-9

ISSN 0306-4573. doi: https://doi.org/10.1016/S0306- 4573(03)00018-9. URL http://www.sciencedirect.com/science/article/pii/S0306457303000189

doi
[2005]

ISBN 1-58113-963-2

ACM. ISBN 1-58113-963-2. doi: 10.1145/1062455.1062522. URL http://doi. acm.org /10.1145/1062455.1062522
[2006]

doi: 10.1109/ TSE.2006.105

ISSN 0098-5589. doi: 10.1109/ TSE.2006.105

2006
[2007]

ISBN 978-1-59593-882-4

ACM. ISBN 978-1-59593-882-4. doi: 10.1145/1321631.1321660. URL http://doi.acm.org/10.1145/ 1321631.1321660
[2010]

doi: 10.1109/QSIC.2010.11

2010 doi
[2011]

doi: 10.1109/HASE.2011.29

2011 doi

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [2]

ISBN 1-55860-153-8

Morgan Kaufmann Publishers Inc. ISBN 1-55860-153-8. URL http://dl.acm.org/citation.cfm?id=645920.672836

work page arXiv

[2] [3]

Agrawal, T

R. Agrawal, T. Imielin´ski, and A. Swami. Mining association rules between sets of items in large databases. In Proceedings of the 1993 ACM SIGMOD International Conference on Management of Data (SIGMOD ’93), pages 207–216, New York, NY, USA,

work page 1993

[3] [4]

S. Brin, R. Motwani, J. D. Ullman, and S. Tsur. Dynamic Item-set Counting and Implication Rules for Market Basket Data. In Proceedings of the 1997 ACM SIGMOD International Conference on Management of Data (SIGMOD ’97), pages 255–264, New York, NY, USA,

work page 1997

[4] [8]

Dallmeier, C

V. Dallmeier, C. Lindig, and A. Zeller. Lightweight Defect Localization for Java. In Andrew P. Black, editor, ECOOP 2005 - Object-Oriented Programming, pages 528–550, Berlin, Heidelberg,

work page 2005

[5] [10]

ISBN 1-58113-993-4

ACM. ISBN 1-58113-993-4. doi: 10.1145/1101908.1101979. URL http://doi.acm.org/10.1145/1101908.1101979

arXiv

[6] [15]

J. A. Jones, M. J. Harrold, and J. Stasko. Visualization of Test Information to Assist Fault Localization. In Proceedings of the 24th International Conference on Software Engineering (ICSE 2002), pages 467–477, May

work page 2002

[7] [16]

J. A. Jones, J. F. Bowring, and M. J. Harrold. Debugging in Parallel. In Proceedings of the 2007 International Symposium on Software Testing and Analysis (ISSTA ’07), pages 16–26, New York, NY, USA,

work page 2007

[8] [17]

ISBN 978-1-59593-734-6

ACM. ISBN 978-1-59593-734-6. doi: 10.1145/1273463.1273468. URL http://doi.acm.org/10.1145/1273463.1273468

arXiv