Proceedings Article10.1145/376656.376848
Multithreaded Java program test generation
Orit Edelstein,Eitan Farchi,Yarden Nir,Gil Ratsaby,Shmuel Ur +4 more
- 01 Jun 2001
- pp 181
TL;DR: ConTest, a tool for detecting synchronization faults in multithreaded Java programs that makes random or coveragebased decisions as to whether the seeded primitive is to be executed, increases the probability of finding concurrent faults.
read more
Abstract: We describe ConTest, a tool for detecting synchronization faults in multithreaded Java™ programs. The program under test is seeded with a sleep(), yield(), or priority() primitive at shared memory accesses and synchronization events. At run time, ConTest makes random or coverage-based decisions as to whether the seeded primitive is to be executed. Thus, the probability of finding concurrent faults is increased. A replay algorithm facilitates debugging by saving the order of shared memory accesses and synchronization events.
read more
Chat with Paper
AI Agents for this Paper
Find similar papers on Google Scholar, PubMed and Arxiv
Write a critical review of this paper
Analyze citations of this paper to find unaddressed research gaps
Citations
Automatic software repair: a survey
Luca Gazzola,Daniela Micucci,Leonardo Mariani +2 more
- 27 May 2018
TL;DR: A new class of approaches, namely program repair techniques, whose key idea is to try to automatically repair software systems by producing an actual fix that can be validated by the testers before it is finally accepted, or that is adapted to properly fit the system.
Falcon: fault localization in concurrent programs
Sangmin Park,Richard Vuduc,Mary Jean Harrold +2 more
- 01 May 2010
TL;DR: A new dynamic fault-localization technique that can pinpoint faulty data-access patterns in multi-threaded concurrent programs and effectively and efficiently localize the faults for subjects is presented.
165
ConSeq: detecting concurrency bugs through sequential errors
Wei Zhang,Junghee Lim,Ramya Olichandran,Joel Scherpelz,Guoliang Jin,Shan Lu,Thomas Reps +6 more
- 05 Mar 2011
TL;DR: ConSeq's backwards approach, (3)!(2)!(1), provides advantages in bug-detection coverage and accuracy but is challenging to carry out, because phases (2) and (3) usually are short and occur within one thread.
Testing Concurrent Java Programs using Randomized Scheduling
TL;DR: The approach discussed here is more scalable but less systematic, which transforms a given Java program by inserting calls to a scheduling function at selected points, ensuring that for each reachable deadlock and assertion violation, there is a sequence of choices by the scheduling function that leads to it.
141
Reachability testing of concurrent programs
Yu Lei,Richard H. Carver +1 more
TL;DR: A general execution model for concurrent programs that allows reachability testing to be applied to several commonly used synchronization constructs is presented and a new method for performing reachable testing is presented.
135
References
Towards integration of data race detection in DSM systems
A. Itzkovitz
- 01 Jan 1999
TL;DR: The integration of on-the-fly data race detection during the regular dsm execution feasible for the first time is presented, and the performance figures show that the mechanism has only a minor influence on performance.
50
Testing races in parallel programs with an OtOt strategy
Suresh K. Damodaran-Kamal,Joan M. Francioni +1 more
- 01 Aug 1994
TL;DR: This paper presents a run-time algorithm with polynomial time complexity (O(pkg(n))) for testing for the occurrence of undesired races in a class of message passing parallel programs.
37
A formal framework for the study of concurrent program testing
TL;DR: The author has developed a formal theory for reasoning about concurrent program testing by representing such programs as sets of simulating sequential programs and has shown that if such a representation exists for all programs in a concurrent language, then it serves as the basis for a solution to the reproducible testing problem of programs in that language.
37
Debugging concurrent processes: a case study
J. M. Stone
- 01 Jun 1988
TL;DR: A method of debugging concurrent processes in a parallel programming environment using a new approach called speculative replay to reconstruct the behavior of a program from the histories of its individual processes and ongoing work on tools that will control replay without reconstructing the entire space of possible event orderings is described.
32