1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
|
<!DOCTYPE html>
<html>
<head>
<title>
The Codex »
Intro to Debuggers
</title>
<link
rel='stylesheet'
type='text/css'
href='http://fonts.googleapis.com/css?family=Buenard:400,700&subset=latin,latin-ext'>
<link
rel="stylesheet"
type="text/css"
href="../media/css/reset.css">
<link
rel="stylesheet"
type="text/css"
href="../media/css/grimoire.css">
</head>
<body>
<div id="shell">
<ol id="breadcrumbs">
<li class="crumb-0 not-last">
<a href="../">index</a>
</li>
<li class="crumb-1 not-last">
<a href="./">dev</a>
</li>
<li class="crumb-2 last">
debugger-101
</li>
</ol>
<div id="article">
<h1 id="intro-to-debuggers">Intro to Debuggers</h1>
<p>(Written largely because newbies in <a href="http://evanchooly.com">##java</a> never seem
to have this knowledge.)</p>
<p>A “debugger” is a mechanism for monitoring and controlling the execution of
your program, usually interactively. Using a debugger, you can stop your
program at known locations and examine the <em>actual</em> values of its variables
(to compare against what you expected), monitor variables for changes (to see
where they got the values they have, and why), and step through code a line at
a time (to watch control flow and verify that it matches your expectations).</p>
<p>Pretty much every worthwhile language has debugging support of some kind,
whether it's via IDE integration or via a command-line debugger.</p>
<p>(Of course, none of this helps if you don't have a mental model of the
“expected” behaviour of the program. Debuggers can help you read, but can't
replace having an understanding of the code.)</p>
<h2 id="debugging-your-first-program">Debugging Your First Program</h2>
<p>Generally, you start running a debugger because you have a known problem -- an
exception, or code behaving strangely -- somewhere in your program that you
want to investigate more closely. Start by setting a <em>breakpoint</em> in your
program at a statement slightly before the problem area.</p>
<p>Breakpoints are instructions to the debugger, telling it to stop execution
when the program reaches the statement the breakpoint is set on.</p>
<p>Run the program in the debugger. When it reaches your breakpoint, execution
will stop (and your program will freeze, rather than exiting). You can now
<em>inspect</em> values and run expressions in the context of your program in its
current state. Depending on the debugger and the platform, you may be able to
modify those values, too, to quickly experiment with the problem and attempt
to solve it.</p>
<p>Once you've looked at the relevant variables, you can resume executing your
program - generally in one of five ways:</p>
<ul>
<li>
<p><em>Continue</em> execution normally. The debugger steps aside until the program
reaches the next breakpoint, or exits, and your program executes normally.</p>
</li>
<li>
<p>Execute the <em>next</em> statement. Execution proceeds for one statement in the
current function, then stops again. If the statement is, for example, a
function or method call, the call will be completely evaluated (unless it
contains breakpoints of its own). (In some debuggers, this is labelled “step
over,” since it will step “over” a function call.)</p>
</li>
<li>
<p><em>Step</em> forward one operation. Execution proceeds for one statement, then
stops again. This mode can single-step into function calls, rather than
letting them complete uninterrupted.</p>
</li>
<li>
<p><em>Continue to end of function</em>. The debugger steps aside until the program
reaches the end of the current function, then halts the program again.</p>
</li>
<li>
<p><em>Continue to a specific statement</em>. Some debuggers support this mode as a
way of stepping over or through “uninteresting” sections of code quickly and
easily. (You can implement this yourself with “Continue” and normal
breakpoints, too.)</p>
</li>
</ul>
<p>Whenever the debugger halts your program, you can do any of several things:</p>
<ul>
<li>
<p>Inspect the value of a variable or field, printing a useful representation
to the debugger. This is a more flexible version of the basic idea of
printing debug output as you go: because the program is stopped, you can
pick and choose which bits of information to look at on the fly, rather than
having to rerun your code with extra debug output.</p>
</li>
<li>
<p>Inspect the result of an expression. The debugger will evaluate an
expression “as if” it occurred at the point in the program where the
debugger is halted, including any local variables. In languages with static
visibility controls like Java, visibility rules are often relaxed in the
name of ease of use, allowing you to look at the private fields of objects.
The result of the expression will be made available for inspection, just
like a variable.</p>
</li>
<li>
<p>Modify a variable or field. You can use this to quickly test hypotheses: for
example, if you know what value a variable “should” have, you can set that
value directly and observe the behaviour of the program to check that it
does what you expected before fixing the code that sets the variable in a
non-debug run.</p>
</li>
<li>
<p>In some debuggers, you can run arbitrary code in the context of the halted
program.</p>
</li>
<li>
<p>Abort the program.</p>
</li>
</ul>
</div>
<div id="comments">
<div id="disqus_thread"></div>
<script type="text/javascript">
/* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */
var disqus_shortname = 'grimoire'; // required: replace example with your forum shortname
/* * * DON'T EDIT BELOW THIS LINE * * */
(function() {
var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js';
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
})();
</script>
<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
<a href="http://disqus.com" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a>
</div>
<div id="footer">
<p>
The Codex —
Powered by <a href="http://markdoc.org/">Markdoc</a>.
<a href="https://bitbucket.org/ojacobson/grimoire.ca/src/master/wiki/dev/debugger-101.md">See this page on Bitbucket</a> (<a href="https://bitbucket.org/ojacobson/grimoire.ca/history-node/master/wiki/dev/debugger-101.md">history</a>).
</p>
</div>
</div>
</body>
</html>
|
