IssueTracker

I should also say that I've removed .android and .AndroidStudio1.2 folder without no change in result.

Siva, can you take a look at this one?

I found this suspicious dependency in the thread dump:

Device List Monitor / java.lang.Thread.State: RUNNABLE
        at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
        at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
        at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
        at sun.nio.ch.IOUtil.read(IOUtil.java:197)
        at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
        - locked <0x00000007cae31278> (a java.lang.Object)
        at com.android.ddmlib.AdbHelper.read(AdbHelper.java:761)
        at com.android.ddmlib.AdbHelper.read(AdbHelper.java:737)
        at com.android.ddmlib.AdbHelper.readAdbResponse(AdbHelper.java:226)
        at com.android.ddmlib.DeviceMonitor.sendDeviceMonitoringRequest(DeviceMonitor.java:700)
        at com.android.ddmlib.DeviceMonitor.startMonitoringDevice(DeviceMonitor.java:530)
        at com.android.ddmlib.DeviceMonitor.updateDevices(DeviceMonitor.java:408)
        - locked <0x00000007cae31338> (a java.util.ArrayList)
        - locked <0x00000007cae31350> (a java.util.ArrayList)

AWT-EventQueue-0 / java.lang.Thread.State: BLOCKED (on object monitor)
        at com.android.ddmlib.AndroidDebugBridge.getDevices(AndroidDebugBridge.java:485)
        - waiting to lock <0x00000007cae31350> (a java.util.ArrayList)
        at com.android.tools.idea.ddms.DevicePanel.updateDeviceCombo(DevicePanel.java:213)
        at com.android.tools.idea.ddms.DevicePanel.access$600(DevicePanel.java:41)
        at com.android.tools.idea.ddms.DevicePanel$3.run(DevicePanel.java:151)

The AWT thread is trying to acquire sLock / sBridgeListeners (the ArrayList at 0x07cae31350), but Device List Monitor is already holding it.

It looks like sometimes, adb doesn't respond back to the "track-jdwp" command. At this point, even a command line "adb jdwp" or "adb devices" will not show anything.

At a high level, ddmlib should be refactored to not have the readers of state (such as "get me the list of devices") block on the same lock used while actually interacting with the device. An interaction with the device is likely to have an unknown delay, and if adb isn't responding, it could even hang. (That requires a timeout as well).

https://android-review.googlesource.com/#/c/157272/ should fix this.

It removes all locking around mDevices in DeviceMonitor, and removes the use of AndroidDebugBridge's internal sLock from being held while reading something from adb.

Note: this should make the IDE not deadlock and be responsive, but there is still something possibly wrong with adb (when it doesn't respond to queries). For now those will require a manual restart of adb server (adb kill-server).

Has it been solved?

#11 I believe we chased down an issue that sounds similar to this but that was only affecting Windows users, which has been applied to the 2.0 release (currently in beta). However, the problem with deadlocks is there's more than one way to cause it. My guess is this issue is fixed but you're seeing another one that looks the same.

So the question for you is, if you're seeing this problem, what version of Android Studio are you using, what's your OS, and what do your logs say? See http://tools.android.com/filing-bugs/studio for more info about how to collect relevant and helpful data for us.