An effective method to control interrupt handler for data race detection

Abstract

Embedded software frequently uses interrupts for timer or I/O processing. If a memory area is used by both an interrupt handler and other routines at the same time, the embedded system has the potential to fail because of unexpected data in the memory. To detect the race conditions of memory, this paper proposes a method of interrupt testing on a CPU emulator. The method consists of two features: one is interrupt generation at the instruction points that possibly causes race conditions; the other is replacing input value from external device to control interrupt handlers. An interrupt is generated just after the program reads or writes data on memory for the purpose of covering all possibility of sharing memory between the interrupt handler and other routines. Sequence of input value from the external device is prepared by hand before program execution. We have applied our method to testing for a race condition of uClinux. The experience of detecting race conditions has shown the mechanism causes interrupts at necessary and sufficient timing compared with random interrupt testing. Also, it is easy to substitute values in memory to detect race conditions.

SimLatte: A Framework to Support Testing for Worst-Case Interrupt Latencies in Embedded Software

“…There has been some work on dealing with interrupts using testing and dynamic analysis techniques [14], [17], [27], [32], [35]. For example, Regehr [27] proposes a random testing technique using a restricted interrupt discipline (RID) to improve naive random testing by eliminating aberrant interrupts.…”

An observable and controllable testing framework for modern systems

“…These techniques, however, focus on thread level concurrency while ignoring concurrency faults caused by interrupts and different processes. Higashi et al [9] improve random testing via a mechanism that causes interrupts to occur at all instruction points to detect interrupt related data races. However, this approach can be both ineffective and inefficient as it cannot determine the location at which to issue an interrupt.…”

Verification of Data Races in Concurrent Interrupt Handlers

“…Table 5 shows the different states of an access history for detecting data races with our protocol in the example program of Figure 2, where accesses to the shared variable msg appear in the first column. When the first access 11 occurs, the label ⟨0, 20, 0⟩⟨20⟩ of the thread segment 1 is simply added into the access history and no data race reported as there is no other access prior to 11 . The next access, 12 , from the thread segment 2 is filtered out because 2 that belongs to task 1 has disabled all interrupts.…”