PMFuzz: test case generation for persistent memory programs

Liu, Sihang; Mahar, Suyash; Ray, Baishakhi; Khan, Samira

doi:10.1145/3445814.3446691

Cited by 30 publications

(19 citation statements)

References 47 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The tool for fuzz testing is called a fuzzer. Due to its simplicity and efficiency, fuzzing has been widely used in the security and system communities [35,41,42,60]. Leveraging fuzz testing to check the correctness and efficiency of PM programs is promising to improve the software quality [35,45].…”

Section: Fuzz Testingmentioning

confidence: 99%

“…We assume that a system crash renders all transient states of all threads/processes lost [23]. This failure model of PM is based on the assumption that CPU registers and caches are volatile, which is commonly used in real hardware (e.g., Intel Optane PM with asynchronous DRAM refresh (ADR) [24,63]), computer systems [28,32,67,70], and PM-specific testing tools [15,19,35,45]. Enhancing CPU caches with durability is possible but requires hardware modifications [1,68] or additional intel-specific extended ADR (eADR) support [50], which are not necessary for PM programming (refer to ğ6.6 for more discussions about eADR).…”

Section: Assumptions and Definitionsmentioning

confidence: 99%

“…Programming PM systems is error-prone due to the existence of crash-consistency bugs [19,35,44,45]. In typical write-back CPU caches, common PM writes are cached in the volatile CPU caches but not immediately flushed (persisted) to PM.…”

Section: Introductionmentioning

confidence: 99%

“…We refer to concurrency bugs that only occur in PM programs (not triggered in non-PM programs) as PM concurrency bugs. Many PM-specific testing tools have been proposed to detect the violations of crash consistency in PM programs by leveraging various mechanisms, e.g., programmer-annotated assertions [37], crashconsistency bug patterns [15,35,36], symbolic execution [45], model checking [20,29], and likely-correctness conditions with output equivalence checking [19], but none targets PM concurrency bugs. In fact, the concurrency bugs triggered only in specific interleavings are known to be more difficult to detect [33,38].…”

Section: Introductionmentioning

confidence: 99%

“…However, for the execution of thread-1 in Figure 2, the update of table pointer is followed by CLWB and SFENCE, which would successfully pass the checking for missing persistency operations, causing false negatives. Some schemes [35,36], including the testing tool in RECIPE [32], inject crashes before persistency instructions and check the crash consistency. However, these tools require expertise for the accurate injection of crashes.…”

mentioning

confidence: 99%

See 4 more Smart Citations

Efficiently detecting concurrency bugs in persistent memory programs

Chen

Hua

Zhang

et al. 2022

Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems

View full text Add to dashboard Cite

Due to the salient DRAM-comparable performance, TB-scale capacity, and non-volatility, persistent memory (PM) provides new opportunities for large-scale in-memory computing with instant crash recovery. However, programming PM systems is error-prone due to the existence of crash-consistency bugs, which are challenging to diagnose especially with concurrent programming widely adopted in PM applications to exploit hardware parallelism. Existing bug detection tools for DRAM-based concurrency issues cannot detect PM crash-consistency bugs because they are oblivious to PM operations and PM consistency. On the other hand, existing PM-specific debugging tools only focus on sequential PM programs and cannot effectively detect crash-consistency issues hidden in concurrent executions.In order to effectively detect crash-consistency bugs that only manifest in concurrent executions, we propose PMRace, the first PM-specific concurrency bug detection tool. We identify and define two new types of concurrent crash-consistency bugs: PM Interthread Inconsistency and PM Synchronization Inconsistency. In particular, PMRace adopts PM-aware and coverage-guided fuzz testing to explore PM program executions. For PM Inter-thread Inconsistency, which denotes the data inconsistency hidden in thread interleavings, PMRace performs PM-aware interleaving exploration and thread scheduling to drive the execution towards executions that reveal such inconsistencies. For PM Synchronization Inconsistency between persisted synchronization variables and program data, PM-Race identifies the inconsistency during interleaving exploration. The post-failure validation reduces the false positives that come from custom crash recovery mechanisms. PMRace has found 14 bugs (10 new bugs) in real-world concurrent PM systems including PM-version memcached.

show abstract

Section: Fuzz Testingmentioning

confidence: 99%