Light: replay via tightly bounded recording

Abstract

Reproducing concurrency bugs is a prominent challenge. Existing techniques either rely on recording very fine grained execution information and hence have high runtime overhead, or strive to log as little information as possible but provide no guarantee in reproducing a bug. We present Light, a technique that features much lower overhead compared to techniques based on fine grained recording, and that guarantees to reproduce concurrent bugs. We leverage and formally prove that recording flow dependences is the necessary and sufficient condition to reproduce a concurrent bug. The flow dependences, together with the thread local orders that can be automatically inferred (and hence not logged), are encoded as scheduling constraints. An SMT solver is used to derive a replay schedule, which is guaranteed to exist even though it may be different from the original schedule. Our experiments show that Light has only 44% logging overhead, almost one order of magnitude lower than the state of the art techniques relying on logging memory accesses. Its space overhead is only 10% of those techniques. Light can also reproduce all the bugs we have collected whereas existing techniques miss some of them.

iReplayer: in-situ and identical record-and-replay for multithreaded applications

“…Some RnR systems require changes to the OS, such as ReVirt [26], Triage [71], Respec [44], and Double-Play [72], which prevents widespread adoption due to security or reliability concerns related to altering the OS. Some utilize static analysis to reduce runtime overhead, such as ODR [5], LEAP [36], CLAP [37], Light [46], and H3 [38]. However, they may exhibit a scalability issue for their offline analysis.…”

“…Second, most existing RnR systems (except RR [55,60]) cannot identically reproduce the recorded execution, as they do not guarantee the same system states, such as process/thread IDs and file descriptors [66,62,5,72,35,54,33,34,37,16,46,52], the same results of system calls (e.g., time) [36,48,37], or have different memory layouts [66,62,5,72,35,54,33,34,37,16,46,52]. Therefore, it is impossible to reproduce some types of bugs: (1) Bugs related to memory layout may not be reliably reproduced.…”

Automated Capturing and Replaying Unit Inputs of C Programs from System Executions through Static and Dynamic Analysis

“…Carving & Replay와 관련된 몇 가지의 연구들이 이 미 존재한다 [9][10][11][12][13][14]. 이 중 일부는 디버깅을 돕거나 오류 상황을 재현하기 위해 개발되었고 [9][10][11], 일부는 스레드 스케쥴링 같은 동시성의 재현을 위해 개발되었다 [12][13][14]. ADDA [9]…”

Efficient Deterministic Replay of Multithreaded Executions in a Managed Language Virtual Machine

“…Data races are common in real software because they are easy to introduce, expensive to detect, and hard to eliminate (Section 8.1). Prior approaches either ignore data races but are thus unsound [22,46]; sidestep the challenge of catching racy interleavings but incur serious limitations [2,26,31,34,42,48,51]; or track dependences explicitly but incur high overhead or other significant limitations [20,27,29,30,34,53]; or rely on custom hardware support [24,25,36,39,43,52] (Section 8.1).…”

“…In order to replay multithreaded executions faithfully, record & replay approaches must record how threads interleave, which includes not only the order of synchronization operations (e.g., the order that two threads acquire the same lock), but also the order of unsynchronized memory accesses (i.e., loads and stores involved in data races)-which is expensive since many accesses can potentially be unsynchronized. Existing record & replay approaches incur high overhead to track cross-thread dependences [29,30], cannot handle racy executions [22,46], rely on speculation and extra cores [31,48], support online or offline replay but not both [2,26,31,34,42,51], or rely on custom hardware [24,25,36,39,52].…”