Automatic repair for multi-threaded programs with Deadlock/Livelock using maximum satisfiability

Lin, Yiyan; Kulkarni, Sandeep S.

doi:10.1145/2610384.2610398

Cited by 27 publications

(16 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Several approaches target at defect classes where the specification is complete, effectively avoiding the problem of weak test suites [11]. Typical defect classes include memory leaks [43], where the specification is semantically equivalent to the original program without leaks, concurrency bugs [44], [45], [46], where the specification is semantically equivalent to the original program without concurrency bugs, and configuration errors [47], where the specification can be interactively queried from the user. Though these approaches have a high precision, they target totally different defect classes compared with our work.…”

Section: Discussionmentioning

confidence: 99%

Precise Condition Synthesis for Program Repair

Xiong

Wang

Yan

et al. 2017

2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE)

261

286

View full text Add to dashboard Cite

Due to the difficulty of repairing defect, many research efforts have been devoted into automatic defect repair. Given a buggy program that fails some test cases, a typical automatic repair technique tries to modify the program to make all tests pass. However, since the test suites in real world projects are usually insufficient, aiming at passing the test suites often leads to incorrect patches. This problem is known as weak test suites or overfitting.In this paper we aim to produce precise patches, that is, any patch we produce has a relatively high probability to be correct. More concretely, we focus on condition synthesis, which was shown to be able to repair more than half of the defects in existing approaches. Our key insight is threefold. First, it is important to know what variables in a local context should be used in an "if" condition, and we propose a sorting method based on the dependency relations between variables. Second, we observe that the API document can be used to guide the repair process, and propose document analysis technique to further filter the variables. Third, it is important to know what predicates should be performed on the set of variables, and we propose to mine a set of frequently used predicates in similar contexts from existing projects.Based on the insight, we develop a novel program repair system, ACS, that could generate precise conditions at faulty locations. Furthermore, given the generated conditions are very precise, we can perform a repair operation that is previously deemed to be too overfitting: directly returning the test oracle to repair the defect. Using our approach, we successfully repaired 17 defects on four projects of Defects4J, which is the largest number of fully automatically repaired defects reported on the dataset so far. More importantly, the precision of our approach in the evaluation is 73.9%, which is significantly higher than previous approaches, which are usually less than 40%.

show abstract

Section: Discussionmentioning

confidence: 99%

Precise Condition Synthesis for Program Repair

Xiong

Wang

Yan

et al. 2017

2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE)

261

286

View full text Add to dashboard Cite

show abstract

“…This work on automatic repair of concurrency bugs has been further extended [103]. Lin et al [99] also insert locks by encoding the problem as a satisfiability one. In Dfixer [17], no new locks are introduced to repair concurrency bugs, instead existing locks are pre-acquired in one thread.…”

Section: Other Oraclesmentioning

confidence: 99%

Automatic Software Repair

2018

View full text Add to dashboard Cite

This article presents a survey on automatic software repair. Automatic software repair consists of automatically finding a solution to software bugs, without human intervention. This article considers all kinds of repair. First, it discusses behavioral repair where test-suites, contracts, models, crashing inputs are taken as oracle. Second, it discusses state repair, also known as runtime repair or runtime recovery, with techniques such as checkpoint and restart, reconfiguration, invariant restoration. The uniqueness of this article is that it spans the research communities that contribute to this body of knowledge: software engineering, dependability, operating systems, programming languages and security. It provides a novel and structured overview of the diversity of bug oracles and repair operators used in the literature.

show abstract

“…ConAir [65] tries to recover most concurrency bugs including deadlock. Lin et al [36] propose to change lock acquisition primitives to the corresponding primitives with trials (e.g., from pthread_mutex_lock to pthread_mutex_trylock) to partially fix a deadlock. They further propose to recover program executions once a deadlock occurs.…”

Section: Concurrency Bug Fixing and Recoverymentioning

confidence: 99%

“…They further propose to recover program executions once a deadlock occurs. However, there are still challenges for recovery from deadlock occurrence as discussed in [36].…”

Section: Concurrency Bug Fixing and Recoverymentioning

confidence: 99%

Radius aware probabilistic testing of deadlocks with guarantees

Cait

Yang

2016

Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering

View full text Add to dashboard Cite

Concurrency bugs only occur under certain interleaving. Existing randomized techniques are usually ineffective. PCT innovatively generates scheduling, before executing a program, based on priorities and priority change points. Hence, it provides a probabilistic guarantee to trigger concurrency bugs. PCT randomly selects priority change points among all events, which might be effective for non-deadlock concurrency bugs. However, deadlocks usually involve two or more threads and locks, and require more ordering constraints to be triggered. We interestingly observe that, every two events of a deadlock usually occur within a short range. We generally formulate this range as the bug Radius, to denote the max distance of every two events of a concurrency bug. Based on the bug radius, we propose RPro (Radius aware Probabilistic testing) for triggering deadlocks. Unlike PCT, RPro selects priority change points within the radius of the targeted deadlocks but not among all events. Hence, it guarantees larger probabilities to trigger deadlocks. We have implemented RPro and PCT and evaluated them on a set of real-world benchmarks containing 10 unique deadlocks. The experimental results show that RPro triggered all deadlocks with higher probabilities (i.e., >7.7x times larger on average) than that by PCT. We also evaluated RPro with radius varying from 1 to 150 (or 300). The result shows that the radius of a deadlock is much smaller (i.e., from 2 to 114 in our experiment) than the number of all events. This further confirms our observation and makes RPro meaningful in practice. CCS Concepts• Software and its engineering➝Deadlocks • Software and its engineering➝Software testing and debugging.

show abstract

Automatic repair for multi-threaded programs with Deadlock/Livelock using maximum satisfiability

Cited by 27 publications

References 20 publications

Precise Condition Synthesis for Program Repair

Precise Condition Synthesis for Program Repair

Automatic Software Repair

Radius aware probabilistic testing of deadlocks with guarantees

Contact Info

Product

Resources

About