Análisis de los componentes volátiles de la semilla de arazá

To replay a piece of previously recorded application, the user chooses a process and an inter- val of execution to replay by selecting the corresponding partial checkpoints. To reproduce a deterministic replay of interleaved shared memory accesses among application processes, vPlay computes a shared memory closure of the selected process and replays all processes in the closure together as a session. A shared memory closure of a process p is the smallest set of processes consisting of p, such that no process within the set shares memory with a process outside the set. All threads within each process in the closure are included in the session and replayed together.

To aid debugging, replay can also be done across consecutive recording intervals by coalescing the partial checkpoints and concatenating the respective logs. The pages re- quired by a process is computed by consolidating the partial checkpoints representing the interval. In particular, the new initial page set is computed by taking the union of initial page sets of individual partial checkpoints. If a particular page address appears in the initial page set of more than one partial checkpoint, the element with non-nil page data in the earliest partial checkpoint is added to the new initial page set. During replay, memory pages accessed by the application are loaded into memory in stages. The application is initially resumed with the pages contained in the initial page set. The rest of the pages accessed by the application during the course of its execution are loaded progressively at each system call that maps the region. When the application makes a system call that maps a new memory region during replay, the corresponding system call

event record would contain the set of pages to be loaded into memory at that point. Virtual replay consists of two phases. (1) Load phase, where the coalesced partial check- point of each process in the session is restored. (2) Replay phase, where the application threads are deterministically re-executed within vPlay’s control. Transition from load phase to re-execute phase occurs when control is transferred to the application code. With vPlay instrumentation, the control is transferred with an implicit sigreturn at the end of the signal handler that loads the processor context. In case of replay through Pin (Section 5.4, control is transferred through a special system call which is intercepted and interpreted by loading the processor context.

Load phase is performed by the partial checkpoint loader. As a part of the load phase, the partial checkpoint loader prepares the process context required for the application to run independent of the target. It includes creating and populating the memory regions, creating the application processes and threads, and loading user created segment descriptor table entries. If the target operating system’s segment layout matches with that of the source and it provides an API to access the tables, vPlay loads the entries into the tables. If not, emulation of instructions that explicitly reference the segments is done by vPlay.

5.2.1 Integration with the Debugger

vPlay integrates with a standard interactive debugger in order to closely monitor and analyze the execution of the application being replayed. The virtual replay mechanism itself just resumes the application and replays it for a specified interval. However, for this process to be useful for root cause analysis, it is necessary to expose the finer steps taken by the application during its execution. Particularly, it is necessary to allow the programmer to set breakpoints at arbitrary functions or instructions, watch the contents of various program variables at each step etc., at the source code level.

vPlay integrates with GDB by providing a GDB script that directs the load phase until the application is fully initialized for the user to start interacting through the debug interface. It also contains the necessary GDB directives to load the symbol information for the application being debugged. The script begins the debugging session with the invocation of the program that performs the load phase as the debuggee, which reads the

partial checkpoint files, reconstructs their address space and initializes their threads. The debugger does not intervene during this process. The latency of the load phase is usually imperceptible to the user. After the application is loaded, a single forward step within the GDB script transfers control to the application code. The application is presented to the user in a stopped state while the debugger shows the register state and the source line of the application a few moments prior to the failure. The user can then set break points, single step through the source lines to examine program variables and monitor application’s interactions with the operating system and other processes, to analyze the root cause.

Any inputs needed by the application are automatically provided by vPlay. For in- stance, when the application attempts to read from the console, the input is directly pro- vided from the log rather than waiting for user input. When the application executes the system call interrupt instruction in a debugging session, the perceived state of the applica- tion’s registers and memory after returning from the instruction would be identical to its state at the corresponding point during recording. Any outputs generated by the applica- tion are captured into an output file. Any graphical output produced by the application may not be directly visible to the user since the window manager may be external to the application and not recorded. However, the user can observe the interactions between the application and the window system within the debugger interface.

When vPlay-user is used, although the instrumentation mechanism itself is based on ptrace, it does not interfere with existing debugger semantics of the ptrace interface. Any ptrace notifications destined to external processes continue to occur. However, as the application executes, the ptrace subsystem generates additional application events in the form of signals that notify vPlay-user agent of the application’s events. Although these events are extraneous to the application, they do not perturb its execution. Most debuggers allow these events to be masked from the user during a debugging session. For example, GDB can be configured to not print the notification signals by adding "handle SIGSYS noprint" to .gdbinit.

Category System Call Linux Windows

Process control

fork emulate with fork emulate with

CreateProcess

clone forward to the OS emulate with

CreateThread

exit group wait for other threads wait for other

threads

Memory geometry

mmap, brk, execve

emulate with mmap and munmap emulate with

VirtualAlloc

shmat, mmap with

MAP SHARED flag

emulate with shmat emulate with

MapViewOfFile

munmap forward to the OS emulate with

UnmapViewOfFile

MMU context set thread area,

modify ldt

forward to the OS update

selector base table

Table 5.1: vPlay system call emulation