Lines Matching full:debugger
3 <title>Dalvik Debugger Support</title>
7 <h1>Dalvik Debugger Support</h1>
28 All of the debugger support in the VM lives in the <code>dalvik/vm/jdwp</code>
30 <code>dalvik/vm/Debugger.c</code> bridges the gap. The goal in doing so
39 typically sits idle until DDMS or a debugger connects. The thread is
40 only responsible for handling requests from the debugger; VM-initated
41 communication, such as notifying the debugger when the VM has stopped at
53 connection from a debugger (either directly or in concert with DDMS).
55 but when the VM sees debugger packets it allocates additional data
66 The JDWP protocol is stateless, so the VM handles individual debugger
67 requests as they arrive, and posts events to the debugger as they happen.
79 that confuse the debugger. For example, re-using registers that hold
82 This can be very confusing for the debugger (and the programmer)
118 acting as a server, the VM waits for a debugger to connect to it.
120 debugger.
124 <dd>If set to 'y', the VM will wait for a debugger connection
125 before executing application code. When the debugger connects (or
126 when the VM finishes connecting to the debugger), the VM tells the
127 debugger that it has suspended, and will not proceed until told
157 for a connection from DDMS, and waiting for a debugger. The program will show
160 debugger to the appropriate DDMS listen port (e.g.
192 The debugger and garbage collector are somewhat loosely
194 debugger is aware of will not be garbage collected until after the
195 debugger disconnects. This can result in a build-up over time while the
196 debugger is connected. For example, if the debugger sees a running
201 debugger.
215 <code>return</code> statements, so when <code>i</code> is 1 the debugger
228 This can also affect the way the debugger processes exceptions. The
229 debugger may decide to break on an
234 method will always be considered "caught", so the debugger won't stop
