IssueTracker

Hey Martin,

Can you please supply a sample along the lines of https://github.com/domesticmouse/MovingMarkerPosition that demonstrates the behavior you are seeing? Thanks!

Hi Brett,
Here you go,
https://github.com/farfromrefug/OverlappingMarkers

Actually not a duplicate.

Version 1.11.0: Correct handling of taps on overlapping markers.

I can say that it works well with markers.
However this should work for any kind of overlay.
Especially polylines.
Would it be possible to add it?
Thanks

Martin,

Please raise a new Feature Request so people can vote on it. Thanks!

I'll try to upload details too. I've been unable to debug ever since I updated to 1.2. Happens on any project (even sample projects) I try to debug. Running AS on Win7x64 and debugging on a Samsung GT-P3110 (Android 4.1.2).

Worked like a dream until I updated to 1.2

[Comment deleted]

I'm going to delete posts that simply say it happens for me too without any reproducible test case. I understand that this issue happens, and it blocks your work. However, we need some useful information.

1. Give us a sample project - does this happen on a project you create with the wizard? IF so, attach that project.
2. Specify what version of Android you are running on.
3. Check if the issue exists if you are on Android 5.0+. There are many bugs in Dalvik that will not be fixed.w

@dev, referring to comment #9, so you're just going to simply ignore everybody that has this problem? Wipe away the "me too" comments?
Everybody reporting this problem isn't working on the same project, so why do we all have to attach sample projects? It's obviously got nothing to do with the projects.

Like I said in one of my previous comments, this problem occurs on ANY project I try to debug. Even the bundled sample projects. ANY project.

But hey, I understand the stress of figuring out what could be causing a bug, and I understand that you need as much info possible to pin point it. I just don't see (perhaps you could enlighten me) why sample projects are needed for this.

Re: comment #11: Maybe you've misunderstood what I have said, and you certainly have not read all the other comments.

1. The problem is not reproducible. If you see the steps reported in the first comment, you'll see that it happens when certain nodes are expanded in the variables view. It doesn't happen all the time, and for me, it doesn't happen even with the nodes expanded.

2. According to comment #28 on Issue 36949180, the issue happens only on certain versions of the platform. That particular user switched to 5.1 and it worked without issues. Of course it is hard for you to read that comment because that bug is filled with comments that simply say "I have this problem too".

So what I am saying is that (and this is applicable to all bugs, not just this one), if all you are going to say is "I see this bug too", then just adding that comment leads to:
 - the bug filled with "me too" comments.
 - Developers not being able to scan through the bug to identify patterns on where the bug happens.
 - Users who report the bug also not being able to see patterns.

You can indicate your interest by just starring the bug. There are over 40 people who have done so. Yet so far I have exactly 2 test cases with instructions, and the problem hasn't shown up for me on either of those 2 test cases.

So help us - give some more specific steps, specify the platform where it happens (many times these issues are on the VM, not in the IDE, so it depends on the Android version). And if you don't have the time to do that, then atleast don't make it hard by posting "me too" comments without any additional info. Everyone already knows that it happens in many different scenarios.

For me this seems to happen on every project. My specs:

Desktop:
Mac OS X 10.10.3
Android Studio 1.2.1.1 (also happened on earlier versions)
JRE 1.6.0.65 (from AS -> about)
JVM Java HotSpot 64-Bit Server VM by Apple Inc. (from AS -> about)
All tools up2date (platform-tools 22)

Device:
Tablet w/ Android 4.1.2 / kernel 3.4.0

"it happens when certain nodes are expanded in the variables view."
That is incorrect, my issue occurred even when no variable pane was present at all.  The issue occurs every time I run my project and debug, so for me it's highly reproducible, in fact so much so that I have gone back to using Eclipse.

"the issue happens only on certain versions of the platform."
That is incorrect.  I was building against 5.1 and the issue occurred every time.  I tried going back all the way to API 10 (the lowest my project would support due to opengl es2.0) and it happened on all them.  Spent many hours trying to get it to work on Samsung tablet, Kindle and Samsung phone, all without success.

I noticed a few other threads mentioning REST API usage.  My project does make HTTP calls (although I am using sockets with port 80, not an HTTP library), so maybe it has something to do with network access and conflict with adb.

Maybe all the "me too"s got the bug elevated from "medium" to "critical"...clearly this product needs alot more regression testing.

Well, if YOU read MY comment, to which you so unpleasantly replied that you were going to delete "me too" comments, you would have noticed that I mentioned some detail and that I'll get some more details uploaded to you.

SO!

1) Like I said, this happens to me, no matter what project I'm debugging and no matter where I put a breakpoint. As soon as I try to step into/over or just resume debugging, it hangs.

2) Like I mentioned, I'm debugging on a Sumsung Tab running 4.1.2.

So what I am saying, is that you're replies aren't helping much when losing your cool.

Tell you what, I'll be using Eclipse until I get a notification that this error has been resolved. Peace on this thread, and on my side.

Thank you and have a great day!

I have a lot of network I/O going on, too. I'm using the gms/drive libs and IaB. Also a lot of multithreading.

Guess we should create a dead simple project with virtually zero threading and zero I/O and check if it happens there, too.

Build: 1.2.1.1, AI-141.1903250, 20150505,

1.8.0_25-b18x64 Oracle Corporation, Windows 8(amd64) v6.2  (1366x768, 1920x1080)

I'm not able to debug any application since I update to Android Studio 1.2. I try with different devices like:
* Samsung S4 (5.0.1).
* Wiko Rainbow Version 8 (4.4.2).
* Galaxy Note III (5.XXX).
* Other samsung devices (Galaxy Tab3, Tab2...)
* Nexus 5 (5.XXX).

When I start debug mode, my applicatons freezes and then debug stills not working. I try to restart the debug but stills blocked.

FYI: It happens every time, not an specific case. I'm not able to work with this issue. Thanks in advance.

@ #14, I don't have any HTTP calls in my app.
@ #16, I'm having this issue even when I debug a simple Hello World app.

Re: comment #9: "There are many bugs in Dalvik that will not be fixed" - how it can be related to dalvik? I don't understand. It worked fine on Android Studio 1.1 I just updated Android Studio and I can't debug at all. Nothing have changed except Android Studio.

Unfortunatelly I can't provide steps to reproduce this bug because it happens in random situations. Sometimes I just hover mouse to variable while debugging, sometimes just hit F8 (step over) and it hangs. I didn't find any particular steps to reproduce it.

What I propose is: when it happens again, can we somehow look what is going on inside Android Studio? I mean - somehow dump process, look at logs if any, look for hung thread in process explorer, etc... Anything that may help.

Using windows 7 x64, Oracle JDK 1.7.75, Android 4.2.2

Dalvik bug was a possibility because of one person mentioning that the issue was resolved when moving to ART. But clearly, it happens with ART as well.

The bug could reside either in IntelliJ or in the platform (ART/Dalvik) - IntelliJ sends a bunch of commands to the VM, and the VM may not have responded back with all that information.

Yes, IntelliJ has changed the debugger architecture in 1.2, but I need to figure out which part is doing the incorrect operation (is the sequence of commands from the IDE incorrect, or the responses from the VM incorrect).

I will try and figure out a way to log the communication between the two. The methods I know so far are cumbersome, but in the absence of a repro case, we'll have to resort to logging.

@vs...@google.com re comment #5 - My Galaxy S3 Mini GT-I8190N is using Android 4.1.2 (API 16). However, I am unhappy to report that - despite very many attempts in the past hour - I have been *unable* to reproduce the bug on the same phone with the same testcase and the same version of Studio (1.2.0, build 141.1890965) in ubuntu 14.04. In other words the debugger behaves as expected! I don't know what has changed since I reported the bug, other than rebooting my PC. I am also even able to debug my regular app normally on the same phone.

I also tried debugging the same testcase on a Huawei Ascend Y550-L01 (Android 4.4.4, API 19) and a Nexus 10 (Android 5.1.1, API 22) and they both worked as expected too.

I don't know where to go from here. I'm really sorry about this. All I can think of, as per #19, is to try another testcase or try to enable verbose logging in the IDE's debugger component. But even the latter's presumably not much use until you have a reliable testcase...

Thanks for the update (and you shouldn't have to apologize about this!)

It seems to lend more credence to the theory that there is a race condition somewhere (still not sure if it is the IDE or the VM), and in certain cases it is triggered. I'll spend some time later today trying to figure out a way to get the debugger communication logs and we can proceed after that..

Could one of you please attach a thread dump of Studio and your process when this happens:

For Studio, do the following:

# find the pid corresponding to Studio
$ jps -mv | grep studio

# obtain the stack dump for that pid
$ jstack -l <pid> >> dump.txt

See http://tools.android.com/filing-bugs/thread-dumps for more details.

For the process on device, do:

# find the pid
$ adb shell ps | grep <package name>

# get the thread dump
$ adb shell kill -3 <pid>

# pull the thread dump from the device to localhost
$ adb pull /data/anr/traces.txt .

In that traces.txt file, we only need the last section corresponding to the pid that you just killed. Thanks.

This is speculation - and I don't have time to try this out right now - but I wonder if there's an interaction between the debugger and the screen lock/unlock behaviour that's causing this bug? When I raised the bug my phone was on swipe-to-unlock (because I hate keep entering the PIN code if the screen locks whilst debugging!). Last night, when I was unable to reproduce the bug, the phone was on its regular use a PIN to unlock the screen. The screen lock/unlock actions might also affect the race condition you mentioned in #22. This could be a complete red herring though!

Ah! Now that's a good idea @dev, #23.
I'll send you the dumps later today. I'm using Windows though. Not sure how I'm going to do those steps on Win. But I'll figure it out.

Thanks. Will send later today.

Re #24 I wasn't able to reproduce the issue on the same testcase and phone (Samsung Galaxy S3 Mini) regardless of whether the screen unlock setting was swipe or PIN. So it looks like that doesn't explain the sudden inability to reproduce it after all; and hopefully someone else can provide the thread dumps you need...

As requested, attaching AS debug dump.
'traces.txt' for some reason didn't work, but maybe just AS dump will help.

AS 1.2 + Genymotion 4.2.2 device
JRE 1.6

Just got "Waiting until last debugger command completes".
Attached please find Android Studio dump.
Unfortunatelly I was unable to obtain dump for process running on a device. Looks like "adb shell kill -3 <pid>" didin't work for some reason. I found correct pid but I was unable to kill process with creating dump.

In my case IDE continued to work. i.e. the editor worked without problem but I was unable to do anything related to debugging. The application on the phone just hung.
I also sometimes catch "Collecting data" bug. But right now I was unable to reproduce it quickly.

I'm using Android Studio 1.2.1.1, Oracle Java 1.7.45, Windows 7 (both windows and java are 64bit)
The phone has Android 4.2.2

[Comment deleted]

[Comment deleted]

Noticed this message:

Waiting for device.
Target device: samsung-gt_i9100-0009f4ba43383f
Uploading file
        local path: C:\Users\alex\Documents\project\ciao\rep\client\Android\GlobalIndoorService\app\build\outputs\apk\app-alex-debug.apk
        remote path: /data/local/tmp/be.ugent.android.globalindoorservice
No apk changes detected. Skipping file upload, force stopping package instead.
DEVICE SHELL COMMAND: am force-stop be.ugent.android.globalindoorservice
Launching application: be.ugent.android.globalindoorservice/be.ugent.android.globalindoorservice.activities.SearchActivity.
DEVICE SHELL COMMAND: am start -D -n "be.ugent.android.globalindoorservice/be.ugent.android.globalindoorservice.activities.SearchActivity" -a android.intent.action.MAIN -c android.intent.category.LAUNCHER
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=be.ugent.android.globalindoorservice/.activities.SearchActivity }

Warning: debug info can be unavailable. Please close other application using ADB: Monitor, DDMS, Eclipse
Restart ADB integration and try again
Waiting for process: be.ugent.android.globalindoorservice

(BTW, I have a definite feeling this is a race issue.)

(And 'Run -> Get thread dump' does nothing)

when testing on a Samsung S2 (GT-i9100)(Android 4.1.2), I get this type of problems, while repeating the same debugging session on a Samsung GT Pro (SM-T325) (Android 4.4.2), debugging seems to work fine.

As for me, I usually attach debugger to a running app, and sometimes it is working smoothly, sometimes it freezes.
Tried with two different devices (Intermec CN 51, android 4.2.2, and Galaxy tab 3 7.0" SM-T211, android 4.4.2), and noticed this behaviour: when I immediately start stepping at a breakpoint (F8 key) I can do one/two steps; if I wait a little more, debugger freezes - when freezes - without letting me to do anything besides killing the app from the device.

I've been having this problem with a Sony Xperia Miro running Android 4.0.4.
What I've noticed is that, with the project I'm currently working on, I can run the debugger a few times with no problems, but eventually it stops working as others have described (App freezes, can't see variables, message in debugger window about waiting for last debugger command to complete, etc.).  When it happens once, it seems to happen constantly until Android Studio is restarted.
It seems pretty random.  The same breakpoint in the same place without any changes to the code can run perfectly fine a few times, then cause the debugger to break.  Running it again, it won't necessarily cause a fault.
On occasion I can detach the debugger from within Android Studio, but other times I have to close it using task manager because it's completely locked up.
I've noticed when I go to close Android Studio in the task manager, both the Android Studio and Java process are using about 1GB of RAM each.  I only seem to get the fault under that circumstance.
Extra Info:
Running Windows 7 64 bit
Android Studio 1.2.1.1 from the Stable channel
All packages in the SDK manager are up to date
Project using Build tools version 22.0.1, Compile SDK API 22, Gradle version 2.2.1, Android Plugin Version 1.2.3.  Using Java/JDK version 8 Update 45 (64 bit).

Sorry, I forgot to mention I'm on Windows 7, android studio 1.2.1.1, jdk 1.8.0_45, building with Jdk 1.7.0_40.

What's interesting is this is freezing up me device as well, so I have to often yank out the usb and force kill the app. Anyway after another hour of rinsing and repeating that to try and evaluate a break point, a File>invalidate cache + restart has made the problem go away for the moment. I'm sure it's temporary but that's a good thing to try if you really need some debugging :)

[Comment deleted]

my solution here
http://stackoverflow.com/questions/29430311/android-studio-1-2-beta-version-hangs-on-debugging/30220465#30220465

Ok, so I couldn't find a consistent reproduction case so far but finally ran into a case where it happens every time today, regardless of device and phone version. It's happening on Android Studio 1.2.1.1. Debug your app and breakpoint anywhere. Then right click a variable and chose "Show Referring Objects". Then the debugger always locks up. Needless to say that the "Show Referring Objects" feature is very useful, if it works.

I've starred this and been lurking here avoiding saying "Me too", but today I am investigating an ANR from my Google Play app and it is locking up every time.
This makes it painful to the users to wait to for the developer to even being to be able to debug the problem.
Please prioritize this or some other related bug to fix this problem.
Thanks,
Pv

I use Genymotion primarily and was having this issue 36904198% of the time after upgrading to Android Studio 1.2. It appears to be an issue with Genymotion's built in tools and the latest Android tools. My fix was to set Genymotion to use my installed Android SDK Tools. I can debug again!!

Genymotion main app -> Settings -> ADB -> Use Custom Android SDK Tools

If other users are having issues and not using Genymotion, then perhaps their ADB version that Android Studio is using is different than the one that shipped with the SDK they built with.

Android SDK Tools 24.2
Android SDK Platform-tools 22
Genymotion HTC One 4.2.2
Genymotion 2.4.0

my solution here:
http://stackoverflow.com/questions/29430311/android-studio-1-2-beta-version-hangs-on-debugging/30220465#30220465

Here's a dump. Invalidating caches and restarting ain't the solution, the issue is occurring shortly after doing that too.

Thank you for the thread dumps so far. We have 3, and unfortunately, all 3 have different sources. What is common is that all 3 are stuck waiting for the target to respond.

So far, we haven't made any progress on this, so I will again make the request that if you have a reproducible test case, please provide that as that'll help us significantly.

I have started a separate thread with Jetbrains asking for help in debugging this, maybe we can collect more accurate debug logs. I will update the thread once we have more info.

Below are the interesting parts of the 3 traces:

---

        at com.sun.tools.jdi.TargetVM.waitForReply(TargetVM.java:300)
        - locked <0x00000000f39111a8> (a com.sun.tools.jdi.Packet)
        at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(VirtualMachineImpl.java:1036)
        at com.sun.tools.jdi.PacketStream.waitForReply(PacketStream.java:69)
        at com.sun.tools.jdi.JDWP$EventRequest$Set.waitForReply(JDWP.java:6910)
        at com.sun.tools.jdi.JDWP$EventRequest$Set.process(JDWP.java:6875)
        at com.sun.tools.jdi.EventRequestManagerImpl$EventRequestImpl.set(EventRequestManagerImpl.java:201)
        - locked <0x00000000e802cb00> (a com.sun.tools.jdi.EventRequestManagerImpl$ClassPrepareRequestImpl)
        at com.sun.tools.jdi.EventRequestManagerImpl$EventRequestImpl.setEnabled(EventRequestManagerImpl.java:166)
        - locked <0x00000000e802cb00> (a com.sun.tools.jdi.EventRequestManagerImpl$ClassPrepareRequestImpl)
        at com.sun.tools.jdi.EventRequestManagerImpl$EventRequestImpl.enable(EventRequestManagerImpl.java:151)
        at com.intellij.debugger.engine.requests.RequestManagerImpl.callbackOnPrepareClasses(RequestManagerImpl.java:316)
        at com.intellij.debugger.ui.breakpoints.Breakpoint.createOrWaitPrepare(Breakpoint.java:194)
        at com.intellij.debugger.ui.breakpoints.BreakpointWithHighlighter.createRequest(BreakpointWithHighlighter.java:310)
        at com.intellij.debugger.engine.JavaBreakpointHandler$1.action(JavaBreakpointHandler.java:56)

--
        at com.sun.tools.jdi.TargetVM.waitForReply(TargetVM.java:300)
        - locked <0x00000000ea187380> (a com.sun.tools.jdi.Packet)
        at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(VirtualMachineImpl.java:1036)
        at com.sun.tools.jdi.PacketStream.waitForReply(PacketStream.java:69)
        at com.sun.tools.jdi.JDWP$ObjectReference$DisableCollection.waitForReply(JDWP.java:4663)
        at com.sun.tools.jdi.JDWP$ObjectReference$DisableCollection.process(JDWP.java:4644)
        at com.sun.tools.jdi.ObjectReferenceImpl.disableCollection(ObjectReferenceImpl.java:420)
        - locked <0x00000000eb641220> (a com.sun.tools.jdi.ObjectReferenceImpl)
        at com.intellij.debugger.engine.SuspendContextImpl.keep(SuspendContextImpl.java:208)
        at com.intellij.debugger.ui.impl.watch.EvaluationDescriptor.calcValue(EvaluationDescriptor.java:133)
        at com.intellij.debugger.ui.impl.watch.ValueDescriptorImpl.setContext(ValueDescriptorImpl.java:188)
        at com.intellij.debugger.engine.JavaValue$1.contextAction(JavaValue.java:137)
        at com.intellij.debugger.engine.events.SuspendContextCommandImpl.action(SuspendContextCommandImpl.java:61)

--

        at com.sun.tools.jdi.TargetVM.waitForReply(TargetVM.java:281)
        - locked <7c1f73d78> (a com.sun.tools.jdi.Packet)
        at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(VirtualMachineImpl.java:1015)
        at com.sun.tools.jdi.PacketStream.waitForReply(PacketStream.java:51)
        at com.sun.tools.jdi.JDWP$ThreadReference$Status.waitForReply(JDWP.java:5095)
        at com.sun.tools.jdi.JDWP$ThreadReference$Status.process(JDWP.java:5076)
        at com.sun.tools.jdi.ThreadReferenceImpl.jdwpStatus(ThreadReferenceImpl.java:185)
        at com.sun.tools.jdi.ThreadReferenceImpl.isSuspended(ThreadReferenceImpl.java:201)
        at com.intellij.debugger.jdi.ThreadReferenceProxyImpl.isSuspended(ThreadReferenceProxyImpl.java:298)
        at com.intellij.debugger.engine.SuspendManagerImpl.isSuspended(SuspendManagerImpl.java:261)

---

Also, please try turning off a few debug options:

1. Turn off inline debugging: https://www.jetbrains.com/idea/help/inline-debugging.html. You can disable it by opening the settings icon in the debug tool window.

2. Settings | Debugger | Java: "Enable alternate views for collections" and "Enable toString() object view"

When started running debug, it works for a while and then whole studio app hangs.
Tried to disable alternate view for collections - does'n help.
Android Studio 1.2, MACOSX Yosemite 10.10.3, Samsung GT-I9152

Comment #46, I don't want to jump the gun, but the debugger-hanging issue has stopped now that I have disabled the Inline debugging. I hope this is the root cause.

>debugger-hanging issue has stopped now that I have disabled the Inline debugging
Confirm

I don't want to spam this thread too much, I know dev hates it, but the issue is now completely gone after disabling inline debugging.

Can anyone else confirm this?

Confirm, the issue seems to be gone after disabling the feature, and
restarting AS

No turning it off has not fixed the issue for me. I'll try restarting now
and test for the rest of the day with it off.

Update: ^ posted that before I saw comment #51 saying to restart. After
restarting with inline debugging off I have my debugger back. Time will
tell if it's a permanent fix :)

On Fri, May 22, 2015 at 11:07 AM, Daniel Wilson <danwilson1702@gmail.com>
wrote:

Well I'm still getting the issue, so I don't believe this is a solution :(

Re: Comment #54: What device/version are you on, and can you reproduce it on ART (5.0 or up)?

Currently testing on a Galaxy Tab GT-P5100 with Android 4.2.2. My phone is a Galaxy S4 GT-I9505 with Android 4.4.2. I had SDK tools 24.1.2 although have just updated.

I'm never on Lollipop these days but will try and see if I can repro it on ART

It doesn't work this solution. I tried with AS 1.2, 1.2.1.1. I try to install AS 1.1.0 again, but still not working.

I'm currently testing with Galaxy S4 (GT-I9505) with Android 5.0.1.

Please, try to fix it ASAP, too many days with this issue...

Re: Comment #55:
I have three devices and all of them hang.
Samsung Galaxy tab 3 lite SM-T111M  Android 4.2.2
Motorola Moto x 2014 Cyanogenmod android 5.1.1
Google Nexus 5 Android 5.1

with the tab 3 it's impossible to work with after two or three line breaks it stops responding and the app just hangs.

the moto x hangs as well but not that often

the nexus 5 with original android 5.1 hangs the a little less than the moto x but it still hangs.

even with inline disabled.

Could you please attach target vm thread dump if possible?

How can I create target vm dump? Steps above (adb shell kill -3 <pid>) doesn't work for me.

@shertz: What is the best way to obtain a thread dump from the target VM? Is there a way to force a thread dump if the target seems unresponsive?

Well here's an AS dump. Still can't get a dump from the device.

Re comment #61: 'adb shell kill -3 <pid>' is the right command (note: /data/anr directory must exists I think). The thread dump may also hang if one of the threads cannot be suspended. ART (5.0+) should print a message in the logcat when getting the signal sent by 'kill -3' though.

Re comment #63: in my case this command does nothing. It doesn't kill the application and doesn't modify the content of /data/anr/traces.txt
Is there any other way to make a dump?

Have the same issue after updates from AS 1.1.0 to 1.2.1.1 (64-Bit)

Turning off inline debugging, "Enable alternate views for collections" and "Enable toString() object view" and restart the IDE did not help.

When debug my sources, debugger hang with message "Waiting until last debugger command completes".

Using Android 4.1.1 Device (SAMSUNG Note 1)

Re comment #64: if that doesn't work, you could take a bugreport using 'adb bugreport &> bugreport.txt'. It will contain the dump of all threads of every running app, including your app. So you just need to copy/paste the one for your app by looking for its pid.

The debugger is still entirely broken on

Build: 1.3 Preview, AI-141.1962279, 20150527,
1.6.0_65-b14-462-11M4609x64 Apple Inc., Mac OS X(x86_64) v10.9.5 unknown (2560x1440, 1920x1200 R)

It is independent of any device (various Nexus, Sony or Samsung devices). Even just clicking around the callstack in the frames window will  break it. Also the Thread-View is always broken and just shows the current paused thread.

We are also getting random native crashes in lib-art, especially if multiple exception are thrown while debugging.

Re #67: Could you please file a separate bug about "We are also getting random native crashes in lib-art, especially if multiple exception are thrown while debugging." ? I'd like to investigate this one too.

Please also indicate the Android version of devices, this is really important. Some issues may have been fixed in later releases. Besides, ART became the default runtime for Android 5.0+ (Dalvik is the default runtime on prior versions).

Thanks you.

Same issue here - nothing seems to help. We always stick with "Waiting until last debugger command completes"

The issue isnt listed in known issues for 1.2 btw.

Any workarround? Just pressed the downgrade Button to 1.1, this helped ;)

Re #68: Created a new ticket: https://code.google.com/p/android/issues/detail?id=175023

Re #68: I've created a small example to reproduce this bug. If you set the breakpoint into line 42 (MainActivity.java) and hit the "resume" button 3-10 times, the debugger keeps "collecting data", the thread view is broken and the app freezes.

Tested devices:
* Nexus 7, Android 5.0.2, Build LRX22G: broken
* Sony Xperia Z1, Android 5.0.2, Build 14.5.A.0.242: broken
* Nexus 5, Android 5.1, Build LMY47I: cannot reproduce
* Nexus 4, Android 4.4.2, Build KOT49H: cannot reproduce

#71: Thank you for the test case! Although I don't see exactly the same problem ("Collecting data"), I do see the debugger get stuck at "Waiting for the last debugger command to complete". Looking into it.

Re #71: Yeah, thanks a lot for that sample! I can reproduce too, even by reducing the number of threads in the pool to 2. This looks like a suspension issue between threads (where at least one thread does not resume). I don't know yet whether the issue is in Android Studio or in the runtime. I'm also investigating that in the runtime.

I noticed that if you configure the breakpoint to only suspend the event thread (not all threads), it's a lot better. Could you please try this to see if that helps?

In the debugger view:
1) Click on 'View breakpoints' icon (or Ctrl+Shift+F8)
2) Select the breakpoint in the list
3) Change the 'Suspend' option from 'All' to 'Thread'

I hadn't had this issue for some time and have since upgraded Studio to 1.2.1.1. However today I'm getting the "Collecting data..." freeze-up a lot whilst debugging my real app, funnily enough whilst trying to sort and look at a list of Strings. Dump attached. TargetVM.waitForReply is under a different call-stack to the ones shown in #45. Unfortunately I couldn't get a dump off the phone (Samsung Galaxy S3 Mini, Android 4.1.2).

adb shell kill -3 <pid> fails with:
/system/bin/sh: kill: <pid>: Operation not permitted

and:
adb bugreport &> bugreport.txt
only creates a file of zero bytes:(.

So far, it looks like some debugger interaction is causing a deadlock inside the target VM. We'll attempt to resolve the issue from comment #71 first as that reproduces fairly well for us.

But in the meantime, you could try turning off inline debugging (see comment #46) and see if that makes a difference. Thanks. For now I think we have enough IDE thread dumps.

Turning off new debugging options and restarting IDE also didn't solved the problem for me. The debugging is nice in first debug session after restart but then it dies. It's killing me, deadline is coming :)

Could you try the suggestion from comment #73:

In the debugger view:
1) Click on 'View breakpoints' icon (or Ctrl+Shift+F8)
2) Select the breakpoint in the list
3) Change the 'Suspend' option from 'All' to 'Thread'

Changing Suspend option All to Thread and make it default looks like solved my issue. I think it's an acceptable and usable solution until the new release. Thx.

[Comment deleted]

Suggestion from comment #73 solved my issue too. Is there any option to change default suspend mode from 'All' to 'Thread'?

[Comment deleted]

Studio 1.3 will make "suspend thread only" the default setting with: https://android-review.googlesource.com/#/c/152785/

Until then, you can do the following:
 - set a breakpoint somewhere
 - open "Run | View Breakpoints"
 - go to one of your breakpoints and change the policy from "All" to "Thread".
 - then click on "Make Default" button

For anyone else who might encounter this issue, here is a summary:

The issue shows up in one of two ways: Studio will be responsive, but the debugger will be stuck at either "Collecting Data.." or "Waiting for last debugger command to complete..". This happens on both Dalivk and ART, so all versions of the platform are affected. The issue is more prevalent with Studio 1.2, but exists on all versions of Studio.

The correct fix for this issue is in the platform. The next version of M preview is likely to have this fix (in progress CL here: https://android-review.googlesource.com/#/c/152715/)

Until then we have some workarounds which reduce the probability of hitting this issue. So if you encounter this issue, you can try one of the following:

1. Change your breakpoint to only suspend the thread where it is hit rather than all threads. See comment #82 for more info on how to do this. The next release of Studio 1.2 and Studio 1.3 will be make this the default. (https://android-review.googlesource.com/#/c/152715/)

2. You can turn off various settings in the debugger that invoke methods: These include:
  a) inline debugging (https://www.jetbrains.com/idea/help/inline-debugging.html)
  b) "Enable 'toString()' object view" (Settings | Debugger | Data Views | Java)
  c) "Enable alternative view for Collections classes" (Settings | Debugger | Data Views | Java)

The 2nd option is more severe (it limits the amount of automation the debugger does for you), so we are not enabling that by default. However, if you still see the issue after changing the suspend policy to thread only, then unfortunately, you'll have to do the steps in 2 as well.

Finally, if you still see the issue after both, then that would be a new bug. Please file a new bug with a test case.

Thanks everyone for your patience and your help in providing us with repro cases and stack traces.

Thanks dev! It's now working, Much appreciated! :)

It works again! Thanks so much!

Workaround in #83 works fine.

I was struggling with debug issues since long time. But I thought its because of my app being huge. But very happy now.

Thanks a ton.

WOrkaround in #83 works for me too.

Thanks a lot.

The Studio workaround fix is included in both 1.2.2 (available in the beta channel) and 1.3 Preview 3 (available in the canary channel).

On newly created projects, Studio should automatically use the "suspend thread only" mode for breakpoints. For existing projects, please follow comment #83.

what is this f... bug:
Waiting until last debugger command completes
i do everything but my problem doesn't solved!
please help me what should i must to do?