[android-developers] Re: How to debug unexpected exceptions (source not found)
On Feb 12, 4:20 pm, Bob Kerns r...@acm.org wrote: However, your test case isn't one that I would expect to reproduce. Instead of throw new ArithmeticException(), which isn't really any different from cases I know to work, try the OP's case: int b = 0; int a = 1/b; //ArithmeticException Tried it; no change. The code path in the VM is essentially the same. Either the throw instruction or the divide integer instruction is going to post an exception, and the common code in the interpreter's exception handling is what posts the exception to the debugger. The VM does filter the exception against the rules the debugger has provided (e.g. class is an instance of RuntimeException, caught or uncaught exceptions), but that bit is pretty straightforward. BTW, a documentation suggestion: Most of the stuff in the Dalvik Debugger Support document you pointed me at is only going to be of interest to geeks like me, but some of it is helpful for anyone trying to debug -- [...] I think a brief article with the highlights -- including points like the debug protocol being debugger-agnostic -- would be a good addition to the developer documentation. Perhaps extend the Debugging Tasks article a bit. We actually had to dial register optimization down substantially to make debugging reasonable. Values would appear and disappear in ways that drove people nuts. dx will generate more efficient code in some circumstances if you disable the debug info. The fancy documentation was written (or at least edited) by tech writers. The stuff in dalvik/docs was written by engineers (e.g. debugger.html is mine). This is probably noticeable in both content and presentation. :-) I can forward your suggestion. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to debug unexpected exceptions (source not found)
On Feb 11, 12:09 am, Bob Kerns r...@acm.org wrote:
I was catching all caught and uncaught RuntimeExceptions.
ArithmeticException is a subclass of RuntimeException, so it SHOULD
have stopped at the point of the throw.
I wrote a simple test:
public static void testThrow() {
try {
System.out.println(throwing);
throw new ArithmeticException(whee);
} catch (RuntimeException re) {
System.out.println(caught);
}
}
I connected to it with jdb, and did the following:
% jdb -attach localhost:8700
1 main[1] catch all java.lang.RuntimeException
Set all java.lang.RuntimeException
1 main[1] cont
Exception occurred: java.lang.ArithmeticException (to be caught at:
android.test.HelloWorld.testThrow(), line=478 bci=15)thread=1
main, android.test.HelloWorld.testThrow(), line=477 bci=14
I also tried it uncaught and it worked that way as well. The
exception is definitely getting reported to the debugger when you
request a break on a subclass of the thrown class.
It's possible Eclipse is ignoring the exception event. I'm not sure
why that would be though.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to debug unexpected exceptions (source not found)
Two other thoughts: (1) I've seen Eclipse display the exception defined by the Android classes and the exception defined by some other VM (either its own or whatever JDK is configured). Make sure you've got the right source for the exception. Since ArithmeticException is working for you I'm guessing this isn't at issue, but figured I'd mention it. (2) If you're really curious you can use jdwpspy to do a man-in-the- middle dump of JDWP traffic. It sits between DDMS and the debugger. It's not a lot of fun to debug the debugger, but it's there if you find yourself drowning in free time and a desire to do marginally unpleasant things. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to debug unexpected exceptions (source not found)
Thanks for the jdwpspy suggestion; I'll collect some more data when I get a chance. Debugging-the-debugger is just my cup of tea, though normally I have the sources at hand. (Grabbing the full Android sources is on my to-do list). However, your test case isn't one that I would expect to reproduce. Instead of throw new ArithmeticException(), which isn't really any different from cases I know to work, try the OP's case: int b = 0; int a = 1/b; //ArithmeticException That's when I observed the problem. My theory is that it is specific to handling of low-level arithmetic, rather than the normal user-code throw. Just a theory, but more plausible than the idea that the bug is more pervasive. (Of course, the observer error explanation is still on the table, as always). BTW, a documentation suggestion: Most of the stuff in the Dalvik Debugger Support document you pointed me at is only going to be of interest to geeks like me, but some of it is helpful for anyone trying to debug -- the synchronized method handling, the merging of return instructions, performance differences, etc. And one I noticed (and expected) but don't see documented, though it touches on a special case of it: variables can disappear as you step in the code, when their values will never be used againn. From register optimization, I expect. I think a brief article with the highlights -- including points like the debug protocol being debugger-agnostic -- would be a good addition to the developer documentation. Perhaps extend the Debugging Tasks article a bit. On Feb 12, 3:11 pm, fadden fad...@android.com wrote: Two other thoughts: (1) I've seen Eclipse display the exception defined by the Android classes and the exception defined by some other VM (either its own or whatever JDK is configured). Make sure you've got the right source for the exception. Since ArithmeticException is working for you I'm guessing this isn't at issue, but figured I'd mention it. (2) If you're really curious you can use jdwpspy to do a man-in-the- middle dump of JDWP traffic. It sits between DDMS and the debugger. It's not a lot of fun to debug the debugger, but it's there if you find yourself drowning in free time and a desire to do marginally unpleasant things. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to debug unexpected exceptions (source not found)
I meant to reply to this earlier. I've seen this before as well, long before Android. So it was one of the first things I checked; I initially expect it to be the problem! As you surmised, I had the right one. On Feb 12, 3:11 pm, fadden fad...@android.com wrote: (1) I've seen Eclipse display the exception defined by the Android classes and the exception defined by some other VM (either its own or whatever JDK is configured). Make sure you've got the right source for the exception. Since ArithmeticException is working for you I'm guessing this isn't at issue, but figured I'd mention it. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to debug unexpected exceptions (source not found)
All supposedly true. I was catching all caught and uncaught RuntimeExceptions. ArithmeticException is a subclass of RuntimeException, so it SHOULD have stopped at the point of the throw. It did not. It stopped later, when a RuntimeException was thrown with the original ArithmeticException as its cause. I believe this is a bug, and the correct behavior is as you describe. Breaking on ArithmeticException explicitly, DID break. I'm guessing this is an interaction between the VM and JDWP implementations, though I didn't experiment to figure out the scope of the issue. Thanks for the pointer to dalvic/docs/debugger.html. I'd observed the behavior from merging return statements, and understood it; it's nice to see it confirmed in writing! I was trying to avoid getting too detailed in my explanation -- but it's also good to have all that detail out there for the broader audience. I'm not sure if you were aiming your explanation at me, or augmenting my explanation to the OP. If the former, perhaps I should mention that my background in compilers, runtimes, and debuggers goes back to the 1970s. I maintained and implemented two Lisp systems at MIT, working with Guy Steele (author of the Java spec), among others. I've done stuff with on-the-fly byte-code generation in Java, JVMTI, and other alphabet soup I can't recall. So maybe it'll carry some weight when I say: nice job on explaining and clariying the details I glossed over. Overall, I've been quite impressed with the JDWP implementation. I have been pleasantly surprised at how few deviations there have been between debugging on Dalvik and JVM. Completely OT, but you might appreciate this: Thanks to the folks behind and magicandroidapps.com, I have ITS -- the PDP-10 operating system that MacLisp ran on at MIT in the 1970's -- running on my Nexus One. I've recently acquired a snapshot of the necessary ITS directories, and hope to get MacLisp up and running on my Nexus One -- faster than on the original systems! On Feb 10, 7:36 pm, fadden fad...@android.com wrote: On Feb 9, 7:09 pm, Bob Kerns r...@acm.org wrote: You may not be seeing what you want because you stop too soon, before it's really created the exception. The debugger stops at the point of the throw. There is no exception variable to examine because there's no exception variable in the source code for the debugger to refer to. The exception object is passed to the debugger when the exception happened event is sent up, so it's free to display it however it chooses to. I expect different debuggers deal with this in different ways, but so long as they're using JDWP to talk to the VM they all get the same set of information. (FWIW, you can connect any debugger you like through DDMS. It's probably easiest to make sure there's only one person talking to the VM at a time if you close Eclipse and use the stand-alone ddms command. I've used jdb, IntelliJ IDEA, and a couple others.) I didn't paste it into this message, but I did look at what was in the exception, I just clicked on the little triangle to expand. It showed the message (Divide by zero), and also showed that the stacktrace field hadn't been filled in yet (which I expected). The stack trace elements are populated on demand. Since most exceptions are never displayed, it's inefficient to go through the trouble of formatting a nice stack trace. There's an array of int[] hiding in there that has the actual info. But, I do spot one anomaly here: I have it set to break on RuntimeException. ArithmeticException is a RuntimeException, but it didn't break. It didn't break until it tried to rethrow it, further up the stack. Make sure you're trapping both caught and uncaught exceptions. An exception is considered caught if there's a finally block anywhere below it, and there are dx-generated finally blocks in all synchronized methods. You end up breaking on a lot of stuff you don't care about, but sometimes it's the only way to really catch the exception. Some notes about the debugger can be found in the source tree in dalvik/docs/debugger.html http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=d... -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to debug unexpected exceptions (source not found)
On Feb 9, 7:09 pm, Bob Kerns r...@acm.org wrote: You may not be seeing what you want because you stop too soon, before it's really created the exception. The debugger stops at the point of the throw. There is no exception variable to examine because there's no exception variable in the source code for the debugger to refer to. The exception object is passed to the debugger when the exception happened event is sent up, so it's free to display it however it chooses to. I expect different debuggers deal with this in different ways, but so long as they're using JDWP to talk to the VM they all get the same set of information. (FWIW, you can connect any debugger you like through DDMS. It's probably easiest to make sure there's only one person talking to the VM at a time if you close Eclipse and use the stand-alone ddms command. I've used jdb, IntelliJ IDEA, and a couple others.) I didn't paste it into this message, but I did look at what was in the exception, I just clicked on the little triangle to expand. It showed the message (Divide by zero), and also showed that the stacktrace field hadn't been filled in yet (which I expected). The stack trace elements are populated on demand. Since most exceptions are never displayed, it's inefficient to go through the trouble of formatting a nice stack trace. There's an array of int[] hiding in there that has the actual info. But, I do spot one anomaly here: I have it set to break on RuntimeException. ArithmeticException is a RuntimeException, but it didn't break. It didn't break until it tried to rethrow it, further up the stack. Make sure you're trapping both caught and uncaught exceptions. An exception is considered caught if there's a finally block anywhere below it, and there are dx-generated finally blocks in all synchronized methods. You end up breaking on a lot of stuff you don't care about, but sometimes it's the only way to really catch the exception. Some notes about the debugger can be found in the source tree in dalvik/docs/debugger.html http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/debugger.html;hb=HEAD -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to debug unexpected exceptions (source not found)
If you are in the debugger, either at a breakpoint or having stepped over some code that justs threw an exception, I have yet to see a case where, after stepping through using the Step Over button, you don't eventually come to a frame that has the exception in it. You can then use the Display window to do ex.printStackTrace(). The stack trace will indicate where. You can actually click on the displayed stacktrace in the console to take you to the source, if it's available! You can do the ex.printStackTrace() in the catch clause of your debugging try/catch statement, too -- but the above technique avoids the need to modify and re-run your code. But it's better to catch it in the act. In the Breakpoints pane, click on the Exceptions Breakpoint icon (it looks like an exclamation point). Enter your selection -- or even Exception if you want to see every single one. Of course, then you have to re-run your code. Except sometimes you can re-execute a higher-level frame, and not restart. Just be aware that the code may not do exactly the same thing in that case, depending on what side-effects the code has already done. I usually run with an Error breakpoint as well. On Feb 8, 11:29 pm, RustedInSeattle guoxiaot...@gmail.com wrote: Hi all, I am pretty new to Android, the thing that bugs me the most about the IDE is that I am not able to get any information about an unexpected exception when it gets thrown, I can put a try catch block around identified code that generates it, but in many cases it takes time to find the line of code that generates the exception. is there any other way I can get the exception information? in JDT when an unexpected exception is thrown the call stack displays the exception class name. but in ADT this doesn't work. Thanks in advance! -Xiaotian -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to debug unexpected exceptions (source not found)
Thanks Bob,
the problem for me is that even I add a Exception breakpoint, and the
when the BP is hit, I still cannot get more information from it, there
is no ex variable I can evaluate. if you want to know what I mean, try
the following code in onCreate of an Activity class:
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.i(TestActivity.class.toString(),onCreate called);
setContentView(R.layout.main);
int b = 0;
int a = 1/b; //ArithmeticException
System.out.print(a); //just to get rid of warning.
}
when the faulty line is hit, debugger stop at the line, but you don't
know what's in that exception, some exception classes carries more
information than the name indicates.
On Feb 9, 3:39 pm, Bob Kerns r...@acm.org wrote:
If you are in the debugger, either at a breakpoint or having stepped
over some code that justs threw an exception, I have yet to see a case
where, after stepping through using the Step Over button, you don't
eventually come to a frame that has the exception in it.
You can then use the Display window to do ex.printStackTrace(). The
stack trace will indicate where. You can actually click on the
displayed stacktrace in the console to take you to the source, if it's
available!
You can do the ex.printStackTrace() in the catch clause of your
debugging try/catch statement, too -- but the above technique avoids
the need to modify and re-run your code.
But it's better to catch it in the act. In the Breakpoints pane, click
on the Exceptions Breakpoint icon (it looks like an exclamation
point). Enter your selection -- or even Exception if you want to see
every single one. Of course, then you have to re-run your code. Except
sometimes you can re-execute a higher-level frame, and not restart.
Just be aware that the code may not do exactly the same thing in that
case, depending on what side-effects the code has already done.
I usually run with an Error breakpoint as well.
On Feb 8, 11:29 pm, RustedInSeattle guoxiaot...@gmail.com wrote:
Hi all,
I am pretty new to Android, the thing that bugs me the most
about the IDE is that I am not able to get any information about an
unexpected exception when it gets thrown, I can put a try catch block
around identified code that generates it, but in many cases it takes
time to find the line of code that generates the exception. is there
any other way I can get the exception information? in JDT when an
unexpected exception is thrown the call stack displays the exception
class name. but in ADT this doesn't work.
Thanks in advance!
-Xiaotian- Hide quoted text -
- Show quoted text -
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: How to debug unexpected exceptions (source not found)
@Bob I don't think you really nailed the problem. I ran into what I think is a similar issue. The stack trace showed the location of the throw deep in the Android API, without a hint of a stack frame from my code. I suppose the problem is because some of the Android code runs in different threads, so that the exception was probably due to some data structure from my code that the API later trips over in another thread. I tried downloading the Android source code and adding it the the Android project source code path. This solved the no source found error in the Eclipse debugger, but unfortunately, the source code line where the exception supposably was thrown didn't show any reasonably rational Android code. I suppose the reason might have been that I pulled down the wrong version of Android source. In the end, my problems were due to not using the API correctly. In one case it was trying to manipulate the UI from the AsyncTask.doInBackground method. In another case it was because it was calling populate several times on a Overlay object instead of just once after all the items had been added. I'd still like to see an answer to the OP because it might be quite educating to step through the Android source code. I usually figure out what went wrong by looking at the the code that actually threw the exception and seeing the data structure that caused it to barf. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: How to debug unexpected exceptions (source not found)
Frank, could this be the little snag I just encountered in replying to RustingInSeattle? Where it doesn't catch RuntimeExceptions thrown from the low level (or maybe any level), unless there's an exact match of class? Can you try your scenario again, this time once you identify the exception class being thrown, set a breakpoint on that specific class, and repeat? I'm not sure exactly where the bug here would lie -- I don't think the ADT plugin supplies anything, so I think it would be on the Android/ SDK side. It's annoying, sure enough. Probably a bit less so if we know it's there, but it would be a real pain for difficult-to-reproduce bugs. Still, getting at the original stack trace, once it's finally printed somewhere, should get you back to your code. If something silently swallows that exception (retry code, perhaps), of course you're out of luck. On Feb 9, 6:38 pm, Frank Weiss fewe...@gmail.com wrote: @Bob I don't think you really nailed the problem. I ran into what I think is a similar issue. The stack trace showed the location of the throw deep in the Android API, without a hint of a stack frame from my code. I suppose the problem is because some of the Android code runs in different threads, so that the exception was probably due to some data structure from my code that the API later trips over in another thread. I tried downloading the Android source code and adding it the the Android project source code path. This solved the no source found error in the Eclipse debugger, but unfortunately, the source code line where the exception supposably was thrown didn't show any reasonably rational Android code. I suppose the reason might have been that I pulled down the wrong version of Android source. In the end, my problems were due to not using the API correctly. In one case it was trying to manipulate the UI from the AsyncTask.doInBackground method. In another case it was because it was calling populate several times on a Overlay object instead of just once after all the items had been added. I'd still like to see an answer to the OP because it might be quite educating to step through the Android source code. I usually figure out what went wrong by looking at the the code that actually threw the exception and seeing the data structure that caused it to barf. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
