TFT: a software system for application-transparent fault tolerance

Bressoud, Thomas

doi:10.1109/ftcs.1998.689462

Cited by 27 publications

(26 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, there is no systematic classification of common types of replica non-determinism, and even less so for the unified handling of such non-determinism. Classifications of some types of replica non-determinism are provided by [4,5,17]. However, those types of non-determinism largely fall within the types of wrappable non-determinism and verifiable pre-determinable non-determinism, with the exception of the non-determinism caused by asynchronous interrupts, which we do not address in this work.…”

Section: Related Workmentioning

confidence: 80%

See 1 more Smart Citation

Design and implementation of a Byzantine fault tolerance framework for non-deterministic applications

et al. 2011

View full text Add to dashboard Cite

Section: Related Workmentioning

confidence: 80%

“…Replica non-determinism for the crash fault model [2,3,4,5,14,16,17,20,24,26] has been studied extensively. However, there is no systematic classification of common types of replica non-determinism, and even less so for the unified handling of such non-determinism.…”

Section: Related Workmentioning

confidence: 99%

Design and implementation of a Byzantine fault tolerance framework for non-deterministic applications

et al. 2011

View full text Add to dashboard Cite

“…Replica nondeterminism has been studied extensively under the benign fault model [2,3,4,5,6,13,14,15,16,17,20]. However, there is a lack of systematic classification of the common types of replica nondeterminism, and even less so on the unified handling of such nondeterminism.…”

Section: Related Workmentioning

confidence: 99%

“…However, there is a lack of systematic classification of the common types of replica nondeterminism, and even less so on the unified handling of such nondeterminism. [4,5,6,17] did provide a classification of some types of replica nondeterminism. However, they largely fall within the types of wrappable nondeterminism and verifiable predeterminable nondeterminism, with the exception of nondeterminism caused by asynchronous interrupts, which we do not address in this work.…”

Section: Related Workmentioning

confidence: 99%

Byzantine Fault Tolerance for Nondeterministic Applications

Zhao

2007

Third IEEE International Symposium on Dependable, Autonomic and Secure Computing (DASC 2007)

View full text Add to dashboard Cite

show abstract

“…Replaying this behavior can be challenging because it requires interrupting the target process at the exact same instruction as during its original execution. Previous approaches [5,6,9,10] have relied on hardware providing a cycle accurate instruction counter [25], but this does not work for CPUs without such counters and does not work for mutable replay. Application changes are extremely likely to change the number and ordering of instructions, rendering the counter values useless.…”

Section: Nondeterministic Interactionsmentioning

confidence: 99%

Transparent mutable replay for multicore debugging and patch validation

2013

View full text Add to dashboard Cite

We present DORA, a mutable record-replay system which allows a recorded execution of an application to be replayed with a modified version of the application. This feature, not available in previous record-replay systems, enables powerful new functionality. In particular, DORA can help reproduce, diagnose, and fix software bugs by replaying a version of a recorded application that is recompiled with debugging information, reconfigured to produce verbose log output, modified to include additional print statements, or patched to fix a bug.DORA uses lightweight operating system mechanisms to record an application execution by capturing nondeterministic events to a log without imposing unnecessary timing and ordering constraints. It replays the log using a modified version of the application even in the presence of added, deleted, or modified operations that do not match events in the log. DORA searches for a replay that minimizes differences between the log and the replayed execution of the modified program. If there are no modifications, DORA provides deterministic replay of the unmodified program.We have implemented a Linux prototype which provides transparent mutable replay without recompiling or relinking applications. We show that DORA is useful for reproducing, diagnosing, and fixing software bugs in real-world applications, including Apache and MySQL. Our results show that DORA (1) captures bugs and replays them with applications modified or reconfigured to produce additional debugging output for root cause diagnosis, (2) captures exploits and replays them with patched applications to validate that the patches successfully eliminate vulnerabilities, (3) records production workloads and replays them with patched applications to validate patches with realistic workloads, and (4) maintains low recording overhead on commodity multicore hardware, making it suitable for production systems.

show abstract

TFT: a software system for application-transparent fault tolerance

Cited by 27 publications

References 10 publications

Design and implementation of a Byzantine fault tolerance framework for non-deterministic applications

Design and implementation of a Byzantine fault tolerance framework for non-deterministic applications

Byzantine Fault Tolerance for Nondeterministic Applications

Transparent mutable replay for multicore debugging and patch validation

Contact Info

Product

Resources

About