Toward Automatic Concurrent Debugging Via Minimal Program Mutant Generation with AspectJ

Copty, Shady; Ur, Shmuel

doi:10.1016/j.entcs.2007.04.001

Cited by 4 publications

(5 citation statements)

References 26 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Researchers have presented a technique to generate the fault‐based test cases for the concurrent systems, in which the faults were injected into the system under test to generate the test purposes. The binary set algorithm was discussed by Shady Copty et al for pinpointing the location of a fault in a concurrent program. The binary set algorithm provided an enhancement over the modified delta debugging algorithm, which was used for searching the set having changes.…”

Section: Overview Of Studiesmentioning

confidence: 99%

A systematic review of approaches for testing concurrent programs

Arora

Bhatia

Singh

2015

Concurrency and Computation

View full text Add to dashboard Cite

SUMMARYConcurrent programs are replacing the sequential programs as they utilize the true capabilities of multicore architecture. The extensive use of multicore systems and multithreaded paradigms warrants more attention to the testing of the concurrent programs. The testing concurrent program is not a new field as it has been more than 40 years because the first problem related to the testing concurrent program was addressed by the researchers. The field covers various domains, which include concurrency problems, testing approaches, techniques, graphical representations, tools, and subject systems. This paper aims at providing an overview of research in the domain of testing concurrent programs by classifying it into eight categories: (a) reachability testing, (b) structural testing, (c) model-based testing, (d) mutation-based testing, (e) slicing-based testing, (f) formal methods, (g) random testing, and (h) search-based testing. The survey is focused on the techniques applied, methodologies followed, and tools used in these aforementioned approaches. Furthermore, the gaps are also identified in different approaches. The paper concludes with the consolidation of various testing parameters along with the future directions.

show abstract

Section: Overview Of Studiesmentioning

confidence: 99%

A systematic review of approaches for testing concurrent programs

Arora

Bhatia

Singh

2015

Concurrency and Computation

View full text Add to dashboard Cite

show abstract

“…These locations were identified using a replay tool called DEJAVU, used on a special deterministic JVM. In a previous paper [6], we applied a new version of the DD algorithm to code from the concurrent bugs benchmark [10]. Using the DD approach and an AspectJ-based implementation of the instrumentation, we were able to pinpoint the bug location in several examples.…”

Section: Using Delta Debugging For Automatic Debuggingmentioning

confidence: 99%

“…Using the open architecture, we implemented two variants of the DD algorithm. The first is the DD algorithm described in [26], and the second is the new DD version from [6].…”

Section: Run the Instrumented Programmentioning

confidence: 99%

“…There are a number of characteristics of the concurrent domain, elaborated in the paper, which cause the problem of finding the root cause to be much harder than in the sequential domain. In a previous paper [6] we showed, on small programs, that the combination of a delta debugging (DD) technique and testing via noise generation yields a concurrent debugging technique. The technique we tried was similar to the techniques expressed in a thread of papers on DD [5], [26], [27].…”

Section: Introductionmentioning

confidence: 99%

“…In [1] and [6] it was shown that concurrent programs are not necessarily monotonic but it was not established if real programs possess this property. One of our first findings was that real programs are not monotonic, and that therefore DD-based search algorithms do not work.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Instrumenting where it hurts

Tzoref

Yom-Tov

2007

Proceedings of the 2007 International Symposium on Software Testing and Analysis

Self Cite

View full text Add to dashboard Cite

As concurrent and distributive applications are becoming more common and debugging such applications is very difficult, practical tools for automatic debugging of concurrent applications are in demand. In previous work, we applied automatic debugging to noise-based testing of concurrent programs. The idea of noise-based testing is to increase the probability of observing the bugs by adding, using instrumentation, timing "noise" to the execution of the program. The technique of finding a small subset of points that causes the bug to manifest can be used as an automatic debugging technique. Previously, we showed that Delta Debugging can be used to pinpoint the bug location on some small programs.In the work reported in this paper, we create and evaluate two algorithms for automatically pinpointing program locations that are in the vicinity of the bugs on a number of industrial programs. We discovered that the Delta Debugging algorithms do not scale due to the non-monotonic nature of the concurrent debugging problem. Instead we decided to try a machine learning feature selection algorithm. The idea is to consider each instrumentation point as a feature, execute the program many times with different instrumentations, and correlate the features (instrumentation points) with the executions in which the bug was revealed. This idea works very well when the bug is very hard to reveal using instrumentation, correlating to the case when a very specific timing window is needed to reveal the bug. However, in the more common case, when the bugs are easy to find using instrumentation (i.e., instrumentation on many subsets finds the bugs), the correlation between the bug location and in- * This work is partially supported by the European Community under the Information Society Technologies (IST) programme of the 6th FP for RTD -project SHADOWS contract IST-035157. The authors are solely responsible for the content of this paper. It does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of data appearing therein.

show abstract