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

Abstract

Reproducing executions of multithreaded programs is very challenging due to many intrinsic and external non-deterministic factors. Existing RnR systems achieve significant progress in terms of performance overhead, but none targets the in-situ setting, in which replay occurs within the same process as the recording process. Also, most existing work cannot achieve identical replay, which may prevent the reproduction of some errors. This paper presents iReplayer, which aims to identically replay multithreaded programs in the original process (under the "in-situ" setting). The novel in-situ and identical replay of iReplayer makes it more likely to reproduce errors, and allows it to directly employ debugging mechanisms (e.g. watchpoints) to aid failure diagnosis. Currently, iReplayer only incurs 3% performance overhead on average, which allows it to be always enabled in the production environment. iReplayer enables a range of possibilities, and this paper presents three examples: two automatic tools for detecting buffer overflows and use-after-free bugs, and one interactive debugging tool that is integrated with GDB.

RIPT -- An Efficient Multi-Core Record-Replay System

“…To solve this problem, RIPT uses a method similar to ODR [2] and iReplayer [4]. RIPT recorder periodically dumps memory of the target program.…”

“…Previous approaches [2,4] depend on pthread API call order or system call order to detect enumeration errors. However, their records are so sparse that complex thread execution order may be performed between two record entries, so it's hard to enumerate the correct memory access order.…”

SmartTrack: Efficient Predictive Race Detection

“…Instead of constructing an event graph, an implementation of DC analysis can either (1) report all DC-races, which are almost always predictable races in practice, or (2) use multithreaded deterministic replay techniques to replay a recorded execution that detected a (previously unknown) DC-race, using DC analysis that constructs an event graph during the replayed execution. Recent record & replay approaches add very low (3%) run-time overhead to record an execution [Liu et al 2018;Mashtizadeh et al 2017]. Replay failure caused by undetected races [Lee et al 2010] is a non-issue since DC analysis detects all races.…”