Automated Concurrency-Bug Fixing Guoliang Jin, Wei Zhang, Dongdong - - PowerPoint PPT Presentation

Automated Concurrency-Bug Fixing

Guoliang Jin, Wei Zhang, Dongdong Deng, Den Libit, Shan Lu (OSDI 2012) Presented by: Kevin Burns October 2, 2013

Outline

Paper Presentation

Background/Motivation CFix Overview

Bug Understanding Fix Strategy Design Synchronization Enforcement Patch Testing and Selection Patch Merging Run-Time Support

Experimentation Setup Results Conclusion

Evaluation (Opinions)

Background

Concurrency related bugs

Common Hard to detect Challenging to avoid Manual intervention is tedious and time consuming Can have drastic consequences in real-world applications

Therac 25 Facebook IPO

Background - Trends/Scope of this work

Existing automated bug fixing tools and techniques

Quickstep Lock operations intelligently inserted from annotations Atomic region detection from profiling

Many bug detectors exist to detect the following:

Data races Order violations Atomicity violations Abnormal inter-thread dependencies

Motivation

No existing automated bug fixing tool with the focus of performance and patch simplicity Need for a flexible framework to support the many exisiting bug detectors

Background - LLVM

source: LLVM’s website http://www.aosabook.org/en/llvm.html

3-stage compiler Makes user optimizations easy via LLVM Intermediate Representation (IR)

Supports lightweight runtime optimizations Cross-function/interprocedural optimizations Whole program analysis Aggressive restructuring transformations

CFix Overview

source: Jin et al.(2012) presentation [3]

A framework to automate the process of concurrency bug fixing Focusses on both Atomicity Violations (AV) and Order Violations (OV) separated into two distinct tools

AFix - Static analysis + code transformation to insert locks to fix AVs OFix - Static analysis and patch generation to fix OVs

All done inside LLVM’s optimizer phase

CFix Stage 1 - Bug Understanding

source: Jin et al.(2012) presentation [3]

CFix Stage 2 - Fix Strategy Design Overview

With a large variation of bugs, how do we design a small subset of strategies to cover all of them? Approach Taken: combine mutual exclusion enforcement and

• rder relationship enforcement

CFix Stage 2 - Fix Strategy Table

source: Jin et al.(2012) paper [2]

CFix Stage 3 - Synchronization Enforcement Overview

How do we verify correctness, while maintaining performance and code simplicity Approach Taken: enforcing both order relationships (OFix) and mutual exclusion (AFix)

CFix Stage 3 - Synchronization Enforcement OFix

Automatically fixes order violations Takes in call stacks as inputs Seperated into two types allA-B and firstA-B

allA-B: operation B cannot execute until all instances of

• peration A has executed

firstA-B: operation B cannot execute until at least one instance of operation A has executed

CFix Stage 3 - Synchronization Enforcement OFix Example

source: Jin et al.(2012) presentation [3] source: Jin et al.(2012) presentation [3]

CFix Stage 3 - Synchronization Enforcement AFix

Four steps to ensure mutual exclusion

Put p and c into critical region Put r into critical region Make the above two regions mutually exclusive to one another Select or introduce a lock to protect the two regions

CFix Stage 3 - Synchronization Enforcement AFix Example

source: Jin et al.(2012) presentation [3]

CFix Stage 4 - Patch Testing and Selection

How do you test a multi-threaded application for correctness? How do you decide which patch is better than the others

CFix Stage 4 - Patch Testing and Selection

Answer: CFix is designed to include patch-oriented testing

Static analysis and interleaving testing Executes the patched software with and without external interference

CFix Stage 5 - Patch Merging

To guarantee simplicity, correctness, and performance, CFix follows four guidelines while patch merging

The final patch must have fewer signal and wait operations than all the individual unmerged patches The bugs must still be fixed Must not generate new deadlocks Significant performance loss is unacceptable

CFix Run-Time Support

Low overhead ongoing process to monitor any future deadlocks appear that didn’t surface during testing

Experimentation Setup

CFix was evaluated on 13 real-world bug cases Seperated into AV and OV bugged applications Identical LLVM settings on an 8-core Intel Xeon running RHEL 5

Results

source: Jin et al.(2012) presentation [2]

Conclusion

Limitations

OFix is not universal order violation bug fixer, only tries 2 different ordering OFix is also limited by it’s use of using call stacks to identify

• perations. Therefore, it cannot fix order violation bugs that
• ccur on the same stack

Conclusions

CFix fixes the more common types of OV and AV For the fixes it does make, performance and code complexity are not greatly compromised Creates great platform for future automated bug fixers CFix’s feedback is valuable to developers and bug detectors

Evaluation (Opinions)

Related work being at the end of the paper No mention of source code release Would like to see more quantitative numbers against existing tools Liked the diagrams and number of examples Definitely a major research contribution Would like to see more clearly defined future work Details on how run-time support were lacking

Bibliography

• G. Jin, L. Song, W. Zhang, S. Lu, and B. Liblit.

Automated atomicity-violation fixing. In ACM SIGPLAN Notices, volume 46, pages 389–400. ACM, 2011.

• G. Jin, W. Zhang, D. Deng, B. Liblit, and S. Lu.

Automated concurrency-bug fixing. In Symposium on Operating System Design and Implementation, 2012a.

• G. Jin, W. Zhang, D. Deng, B. Liblit, and S. Lu.

Cfix automated concurrency-bug fixing. Presented at the Symposium on Operating System Design and Implementation, Hollywood, CA, 2012b.