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 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 source: Jin et al.(2012) presentation [3]
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 order 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 a ll instances of operation 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 operations. Therefore, it cannot fix order violation bugs that occur 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.
Recommend
More recommend
