I've been having frustrating issues with the Android debugger. I can debug and step through code sometimes, then in other parts of the code (lately in try/catch situations), it goes down to the catch {} block and there is no information on the exception and it doesn't even Log.e it to console. Notice how in the screenshot I've stepped into the catch block, but there is no live variable context, its as if it is in normal content assist mode. Watch expressions show <error(s)_during_the_evaluation>.
Can anyone shed light on these frustrating issues I'm having? The weird thing that the debugger works fine in other parts of the code.
Eclipse + ADT is notorious for acting inconsistently, which often leads me to just make sure that Project > Build Automatically is checked and then simply fire up a Project > Clean....
Sometimes even that doesn't help. So I just close Eclipse and re-start it. Works most of the time.
When even this doesn't help, I close Eclipse, run CCleaner and reboot. Works every time.
Weird but true.
You can't always believe your debugger; it's an inexact science. This is especially true when there are multiple code build steps (JVM bytecode, Dalvik code, etc). The debugger often doesn't have 100% of the information necessary to reverse engineer the location in the code back to a source code line.
In the instance above, did your code actually throw an exception, or not? It sounds like it didn't, and the debugger is showing execution on that highlighted line even though it's not really going to execute it.
I would be more inclined to believe the execution of the code - if Log.e() was never called, then you never really got any exception at all.
Related
My Android app runs dead slow (almost frozen) after resuming from a Java breakpoint, even if I disconnect from the debugger or even unplug the USB cable. I get the same behavior on every device and emulator I've tried. Performance is great until it hits the first breakpoint, but it's unusable after I resume and I have to kill it. It's very frustrating.
It used to work great but it started with Android Studio 3.1.x and it's still happening after I upgraded to 3.2.1, then 3.3.2, the latest stable release at this time. None of my colleagues who work on the same app have this problem so it's probably not the code. I suspect I have a configuration issue somewhere.
I have no idea what changed when it started. It happens no matter where the breakpoint is. I don't see any errors in LogCat.
I'm using a MacBook Pro (15-inch, 2017) running OSX 10.13.6, Android Studio 3.3.2 (current stable release) and a Pixel XL running P. Also various emulators running P.
Any ideas or suggestions are much appreciated.
NOTE: It happens on Java breakpoints but not Kotlin.
NOTE: I cannot repro with a simple default app, so it's project specific, but only on my machine.
As #Magudesh stated, method breakpoints are very slow for the android debugger.
It's a lot more useful to just add a line breakpoint in the first line of your method and then (if it's necessary) in the last line.
That will greatly increase performance. If you then want to jump to the next breakpoint you can just hit the green play button in your debugger window.
make sure your debugger is ok .
Don't add breakpoint in the method definition. Method breakpoint will decrese the performance. Go with line breakpoint. That is better.
Please go through the difference b/w method breakpoint and line breakpoint if you are not aware.
Try to remove all the previous breakpoints that you might have added in Android Studio.
Go to the debugger window and select the View Breakpoints option and then disable all the old breakpoints and only add the new one which you want to use.
While working today, it seemed as if suddenly I could no longer debug our application. The funny thing is, if I ran the app normally it would work just fine. To clarify, I was running the debugger all morning without incident (apart from the occasional glitch or crash). Then after lunch it began failing 100% of the time. Of course, I've been making changes all day, hence the "it seems" above. So, here are some relevant details:
Android Studio 2.1.1 (April 28, 2016 build)
This app starts up with a log in screen. The user must then authenticate with a username/password which calls out to an external service.
I can get to the login screen, but the app would always crash at the same point in the middle of the authentication.
Here is the stack trace:
05-24 14:56:25.764 2399-2745/com.mycomp.myapp.test E/Crashlytics: Failed to execute task.
java.lang.InterruptedException
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:375)
at java.util.concurrent.FutureTask.get(FutureTask.java:162)
at com.crashlytics.android.v.a(SourceFile:1936)
at com.crashlytics.android.v.uncaughtException(SourceFile:307)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:693)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:690)
05-24 14:56:25.764 2399-2745/com.mycomp.myapp.test E/AndroidRuntime: FATAL EXCEPTION: pool-5-thread-1
Process: com.mycomp.myapp.test, PID: 2399
java.lang.InterruptedException
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:1991)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2025)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:410)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1035)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1097)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:820)
Here are the things I've tried to fix it:
Back out all my changes (git stash)
Uninstall application from phone
Do a clean build
Do a Gradle Project Resync
Remove all breakpoints (seriously?)
Ok, I've been adding breakpoints all over to see how things work, so who knows? There's some merit there.
Restart Android Studio! (turn it off and on again)
And so far, nothing works. However, I can't emphasize enough that if I just run the app (play button, ^R) and run it on the very same device, it works just fine! Log in with no problem. So, it doesn't seem to be a code problem.
Furthermore, if you look at the stack trace, there is nothing pointing to our project.
Any ideas?
Well, I figured it out. It turns out I had a "Java Field Watchpoint" selected with "Suspend Thread" as one of the options. See the attached screenshot for clarification. Takeaways:
As you can see, I had been using a bunch of breakpoints, so it got buried in the window and I didn't see it.
I still don't know how it got set. I had been using watches on a previous day, but I had deleted them all. Furthermore, I'm quite certain I didn't turn it on, so how it mysteriously stopped working in the middle of the day is still a mystery. Also, I certainly wouldn't have checked "suspend thread" on my own. Some sort of default setting?
Point remains - if you are seeing weird stack traces, it might be good to check all the breakpoints and watch point settings.
I hope this helps someone.
Instant Run appears to be the culprit (at least in my case with Android Studio 2.3.3). Instead of disabling breakpoints, try disabling Instant Run. Once I did this, breakpoints ceased to cause crashes.
See Android app crashes when launched in debug mode for details. Under Mac OS X, I disabled Instant Run by going to Android Studio->Preferences->Build, Execution, Deployment->InstantRun and unchecking "Enable Instant Run to hot swap ...".
There is a "Having trouble with Instant Run?" message displayed in the settings panel. I clicked on "Re-enable and activate extra logging", reproduced the crash, and then immediately reported using the "Help - Report Instant Run Issue..." option as they requested.
Turn off instant run, It'll fix all the issues
I changed emulators (from Android 8.1 to Android 7.0) and did not experience this again. I wasted 3 hours on this. I hope I help someone by suggesting this.
I'm debugging my Android project in Android Studio using breakpoints.
I've noticed sometimes my breakpoints have a cross in them and don't pause execution.
On the intellij site this is explained as: "Shows when the breakpoint is set on a commented or non-executable line indicating that such breakpoint would not be hit."
Could anyone tell me how the above summary can explain the behaviour of the following breakpoints:
Why does the second breakpoint have a tick? I'm confused!
that's usually because the code on the connected device is different than the code on your screen.
In different words, the debugger "knows" where a break point is based on the line number on the code, so you probably added lines of code, and by that moved the line position a few lines down.
Super simple way to fix that is compile the code and flash again on the device.
So far I bought a half dozen Android books and yet couldn't find one that talks about debugging in a reasonable depth other than just scratching the surface.
I'm getting really frustrated about the fact that the debugger, when finds a problem, some times shows you the line in your code where the problem is happening and other times it just shows the "source not found" error in the class file editor. (I attached the screen-shot below).
When the debugger shows the line (in your code) where the execution stops it is clear to understand what's happening and easy to figure out what the problem is.
But when you get the "source not found" message it's really hard to figure where the problem is happening, don't even know where to start and I have to put breakpoints all over the place until I can reduce the area and pin point the problem.
Doing it that way is really... really... time consuming, what should I do when the "source not found" appears, where do I get a clue of the location of the problem? Is there some view or something else that I'm missing? How do you guys do it when that happens? Thanks in advance.
The line will always be printed in the logcat. Just hit run until it stops breaking, and check the logfile. It gives the complete stack trace there.
Ok, I'm going to be the geeezer jerk for a minute. A debugger is a crutch. Your first reaction as a programmer should always be to check the log file. The log file will generally give context, and you won't always be able to run a debugger (you're running on an interrupt, the code is running on a remote machine you don't have access to, the code is running a language that doesn't have exceptions, the crash is a hard crash and brings down the computer, etc). Checking the debugger should be step 3 or 4, not step 1.
I couldn't find the answer to this on SO, so I thought I would submit a question/answer.
I'm not sure if this is version specific, so just in case it is I'm running Eclipse 3.7.2 and ADT 18.0.0.v201203301601-306762
Developing for ICS.
I spent a good portion of the morning running trying to debug my app. I would go up to the little green bug, and click on my project.
The Launch indicator starts at the bottom, fills all the way up to 100% then nothing. No errors, no log output, no logcat messages, nothing under console. For the most part, there is no output indication that something has gone wrong. It just doesn't launch.
I have been switching between and HTC device and an emulator for debugging - mostly using the device for tests right before a release.
So I thought I would plug the HTC in and try again. Plugged it in, logcat started rolling, clicked on the de-bug, same thing. No output, no logs, nothing. It just doesn't launch.
Answer.
I finally decided to (though this should have probably been one of the first things I did, however because there were no errors or log outputs, I thought this was something exotic.) check the debug configurations. Turns out that under the Target tab, the deployment mode somehow got switched to Automatic. However, I had recently deleted a virtual device. This lead to an Automatic launch, with no device selected for the launch. Thus, the launch was automated with no end point.
To me, it seems there should be some sort of error message for this sort of thing, something like, "You have not selected a device" or "Please select a device", which is why I immediately suspected a more serious issue - but hey, I'm just a developer.
At any rate, all I had to do, obviously, was to set it back to Manual and voila, she's a kickin' again.
Some may think this is a no brainer, while others more slightly crazy with a tendency to distort reality may end up having the same problem I did. So, in sympathy to the crazy/distorted reality type - here's the answer :)