summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAndy McFadden <fadden@android.com>2009-04-24 15:18:42 -0700
committerAndy McFadden <fadden@android.com>2009-04-24 15:18:42 -0700
commit10d42fab90518b4e41739d855155f01f335fb7ee (patch)
tree5e0ff27c3d5655f21173de4e0d80dc2d077b1e06
parent687103089b24beba994312bd123dc91fa378ee36 (diff)
downloadandroid_dalvik-10d42fab90518b4e41739d855155f01f335fb7ee.tar.gz
android_dalvik-10d42fab90518b4e41739d855155f01f335fb7ee.tar.bz2
android_dalvik-10d42fab90518b4e41739d855155f01f335fb7ee.zip
Updated the "weird stuff you might see" section.
-rw-r--r--docs/debugger.html34
1 files changed, 34 insertions, 0 deletions
diff --git a/docs/debugger.html b/docs/debugger.html
index 6e23f0df2..7d93caf08 100644
--- a/docs/debugger.html
+++ b/docs/debugger.html
@@ -202,6 +202,40 @@ list, even if the debugger never sees them. Having a debugger attached
to a program that throws lots of exceptions can result in out-of-memory
errors. This will be fixed in a future release.
</p><p>
+&nbsp;
+</p><p>
+The translation from Java bytecode to Dalvik bytecode may result in
+identical sequences of instructions being combined. This can make it
+look like the wrong bit of code is being executed. For example:
+<pre> int test(int i) {
+ if (i == 1) {
+ return 0;
+ }
+ return 1;
+ }</pre>
+The Dalvik bytecode uses a common <code>return</code> instruction for both
+<code>return</code> statements, so when <code>i</code> is 1 the debugger
+will single-step through <code>return 0</code> and then <code>return 1</code>.
+</p><p>
+&nbsp;
+</p><p>
+Dalvik handles synchronized methods differently from other VMs.
+Instead of marking a method as <code>synchronized</code> and expecting
+the VM to handle the locks, <code>dx</code> inserts a "lock"
+instruction at the top of the method and an "unlock" instruction in a
+synthetic <code>finally</code> block. As a result, when single-stepping
+a <code>return</code> statement, the "current line" cursor may jump to
+the last line in the method.
+</p><p>
+This can also affect the way the debugger processes exceptions. The
+debugger may decide to break on an
+exception based on whether that exception is "caught" or "uncaught". To
+be considered uncaught, there must be no matching <code>catch</code> block
+or <code>finally</code> clause between the current point of execution and
+the top of the thread. An exception thrown within or below a synchronized
+method will always be considered "caught", so the debugger won't stop
+until the exception is re-thrown from the synthetic <code>finally</code> block.
+</p><p>
<address>Copyright &copy; 2009 The Android Open Source Project</address>