next up previous
Next: 3.4 Files Up: 3.3 Shared Libraries Previous: 3.3.1 Checkpointing Mapped Segments

3.3.2 Restoring Mapped Segments

On restart, Condor must restore all segments in the checkpoint file. The data segment is restored as in static checkpointing. Condor restores the stack segment last, and returns to the top of the stack as if returning from a signal handler.

To restore the dynamic libraries, Condor first uses the mmap() function to allocate the necessary mapped segment in the virtual address space. This call maps the file /dev/zerogif from the appropriate start address to end address, to provide an initialized segment. The protection and attribute flags for this new segment are set to be those saved in the checkpoint file, except that the segment always has write access enabled and the memory is always marked as private. Write access is necessary so that the saved bytes in the checkpoint file can be written to the segment. The memory is not shared to ensure that our (possibly different) version of a system library does not interfere with other processes on the machine. Once the mapped segment is allocated, the read() system call is used to overwrite the memory with the saved bytes in the checkpoint file.

Note that the definitions for mmap() and write() must be forced to be static. Otherwise, we run into the possibility of overwriting the shared library text segment in which they are defined while we are in a call to either mmap() or write(), which can have disastrous consequences.