1<html lang="en"> 2<head> 3<title>Checkpoint/Restart - Debugging with GDB</title> 4<meta http-equiv="Content-Type" content="text/html"> 5<meta name="description" content="Debugging with GDB"> 6<meta name="generator" content="makeinfo 4.13"> 7<link title="Top" rel="start" href="index.html#Top"> 8<link rel="up" href="Running.html#Running" title="Running"> 9<link rel="prev" href="Forks.html#Forks" title="Forks"> 10<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> 11<!-- 12Copyright (C) 1988-2013 Free Software Foundation, Inc. 13 14Permission is granted to copy, distribute and/or modify this document 15under the terms of the GNU Free Documentation License, Version 1.3 or 16any later version published by the Free Software Foundation; with the 17Invariant Sections being ``Free Software'' and ``Free Software Needs 18Free Documentation'', with the Front-Cover Texts being ``A GNU Manual,'' 19and with the Back-Cover Texts as in (a) below. 20 21(a) The FSF's Back-Cover Text is: ``You are free to copy and modify 22this GNU Manual. Buying copies from GNU Press supports the FSF in 23developing GNU and promoting software freedom.'' 24--> 25<meta http-equiv="Content-Style-Type" content="text/css"> 26<style type="text/css"><!-- 27 pre.display { font-family:inherit } 28 pre.format { font-family:inherit } 29 pre.smalldisplay { font-family:inherit; font-size:smaller } 30 pre.smallformat { font-family:inherit; font-size:smaller } 31 pre.smallexample { font-size:smaller } 32 pre.smalllisp { font-size:smaller } 33 span.sc { font-variant:small-caps } 34 span.roman { font-family:serif; font-weight:normal; } 35 span.sansserif { font-family:sans-serif; font-weight:normal; } 36--></style> 37<link rel="stylesheet" type="text/css" href="../cs.css"> 38</head> 39<body> 40<div class="node"> 41<a name="Checkpoint%2fRestart"></a> 42<a name="Checkpoint_002fRestart"></a> 43<p> 44Previous: <a rel="previous" accesskey="p" href="Forks.html#Forks">Forks</a>, 45Up: <a rel="up" accesskey="u" href="Running.html#Running">Running</a> 46<hr> 47</div> 48 49<h3 class="section">4.12 Setting a <em>Bookmark</em> to Return to Later</h3> 50 51<p><a name="index-checkpoint-195"></a><a name="index-restart-196"></a><a name="index-bookmark-197"></a><a name="index-snapshot-of-a-process-198"></a><a name="index-rewind-program-state-199"></a> 52On certain operating systems<a rel="footnote" href="#fn-1" name="fnd-1"><sup>1</sup></a>, <span class="sc">gdb</span> is able to save a <dfn>snapshot</dfn> of a 53program's state, called a <dfn>checkpoint</dfn>, and come back to it 54later. 55 56 <p>Returning to a checkpoint effectively undoes everything that has 57happened in the program since the <code>checkpoint</code> was saved. This 58includes changes in memory, registers, and even (within some limits) 59system state. Effectively, it is like going back in time to the 60moment when the checkpoint was saved. 61 62 <p>Thus, if you're stepping thru a program and you think you're 63getting close to the point where things go wrong, you can save 64a checkpoint. Then, if you accidentally go too far and miss 65the critical statement, instead of having to restart your program 66from the beginning, you can just go back to the checkpoint and 67start again from there. 68 69 <p>This can be especially useful if it takes a lot of time or 70steps to reach the point where you think the bug occurs. 71 72 <p>To use the <code>checkpoint</code>/<code>restart</code> method of debugging: 73 74 75<a name="index-checkpoint-200"></a> 76<dl><dt><code>checkpoint</code><dd>Save a snapshot of the debugged program's current execution state. 77The <code>checkpoint</code> command takes no arguments, but each checkpoint 78is assigned a small integer id, similar to a breakpoint id. 79 80 <p><a name="index-info-checkpoints-201"></a><br><dt><code>info checkpoints</code><dd>List the checkpoints that have been saved in the current debugging 81session. For each checkpoint, the following information will be 82listed: 83 84 <dl> 85<dt><code>Checkpoint ID</code><br><dt><code>Process ID</code><br><dt><code>Code Address</code><br><dt><code>Source line, or label</code><dd></dl> 86 87 <p><a name="index-restart-_0040var_007bcheckpoint_002did_007d-202"></a><br><dt><code>restart </code><var>checkpoint-id</var><dd>Restore the program state that was saved as checkpoint number 88<var>checkpoint-id</var>. All program variables, registers, stack frames 89etc. will be returned to the values that they had when the checkpoint 90was saved. In essence, gdb will “wind back the clock” to the point 91in time when the checkpoint was saved. 92 93 <p>Note that breakpoints, <span class="sc">gdb</span> variables, command history etc. 94are not affected by restoring a checkpoint. In general, a checkpoint 95only restores things that reside in the program being debugged, not in 96the debugger. 97 98 <p><a name="index-delete-checkpoint-_0040var_007bcheckpoint_002did_007d-203"></a><br><dt><code>delete checkpoint </code><var>checkpoint-id</var><dd>Delete the previously-saved checkpoint identified by <var>checkpoint-id</var>. 99 100 </dl> 101 102 <p>Returning to a previously saved checkpoint will restore the user state 103of the program being debugged, plus a significant subset of the system 104(OS) state, including file pointers. It won't “un-write” data from 105a file, but it will rewind the file pointer to the previous location, 106so that the previously written data can be overwritten. For files 107opened in read mode, the pointer will also be restored so that the 108previously read data can be read again. 109 110 <p>Of course, characters that have been sent to a printer (or other 111external device) cannot be “snatched back”, and characters received 112from eg. a serial device can be removed from internal program buffers, 113but they cannot be “pushed back” into the serial pipeline, ready to 114be received again. Similarly, the actual contents of files that have 115been changed cannot be restored (at this time). 116 117 <p>However, within those constraints, you actually can “rewind” your 118program to a previously saved point in time, and begin debugging it 119again — and you can change the course of events so as to debug a 120different execution path this time. 121 122 <p><a name="index-checkpoints-and-process-id-204"></a>Finally, there is one bit of internal program state that will be 123different when you return to a checkpoint — the program's process 124id. Each checkpoint will have a unique process id (or <var>pid</var>), 125and each will be different from the program's original <var>pid</var>. 126If your program has saved a local copy of its process id, this could 127potentially pose a problem. 128 129<h4 class="subsection">4.12.1 A Non-obvious Benefit of Using Checkpoints</h4> 130 131<p>On some systems such as <span class="sc">gnu</span>/Linux, address space randomization 132is performed on new processes for security reasons. This makes it 133difficult or impossible to set a breakpoint, or watchpoint, on an 134absolute address if you have to restart the program, since the 135absolute location of a symbol will change from one execution to the 136next. 137 138 <p>A checkpoint, however, is an <em>identical</em> copy of a process. 139Therefore if you create a checkpoint at (eg.) the start of main, 140and simply return to that checkpoint instead of restarting the 141process, you can avoid the effects of address randomization and 142your symbols will all stay in the same place. 143 144 <div class="footnote"> 145<hr> 146<h4>Footnotes</h4><p class="footnote"><small>[<a name="fn-1" href="#fnd-1">1</a>]</small> Currently, only 147<span class="sc">gnu</span>/Linux.</p> 148 149 <hr></div> 150 151 </body></html> 152 153