Bug 4270 - Select device dialog becomes unusable after refreshing devices a number of times.
Summary: Select device dialog becomes unusable after refreshing devices a number of ti...
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Android Add-in ()
Version: 2.9.x
Hardware: PC Mac OS
: Normal blocker
Target Milestone: ---
Assignee: Alan McGovern
Depends on:
Reported: 2012-04-05 13:27 UTC by PJ
Modified: 2012-04-19 16:15 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description PJ 2012-04-05 13:27:56 UTC
This bug is a faint echo of 1734.

Now, refreshing the list does not crash, but the Refresh button does become permanently disabled after a few rapid attempts.

Workaround is to just close the dialog and re-run the app.
Comment 1 Alan McGovern 2012-04-05 15:05:22 UTC
Rodrigo, is it possible that we papered over the actual bug by ignoring the error condition when the destination machport does not exist? Could we have turned the abort into a silent failure with commit 02a2af110f4a0ffc77d75ea658baa6ddd2f5a6de in the mono tree?
Comment 2 Rodrigo Kumpera 2012-04-05 16:30:26 UTC
Alan, yes, it's possible. To verify that, check if the target thread gets stuck.

In the meanwhile, stop using Thread.Abort.
Comment 3 Alan McGovern 2012-04-10 12:42:07 UTC
Fixed in commit 1c61e7f7. We were handling errors in such a way as to cause the refresh button to never reenable if there was a problem.
Comment 4 PJ 2012-04-17 17:15:06 UTC
We are still seeing this issue in MD master. Report from last night's testing:

Steps to reproduce: 
1. Create a new solution or open the existing solution.
2. Click on Run button from menu bar.
3. Select the emulator and click on start emulator.
4. Refresh the select device window multiple times(around 50 times).
5. Observe that, on the select device pop-up the refresh button get disabled after multiple clicks.

Actual result: On the select device pop-up, when click on the refresh button multiple times, the refresh button get disabled, and the user have to restart the MonoDevelop in order to make it enabled.

Expected result: On the select device pop-up when click on refresh button multiple times, the device list may go blank for a few moments at a time, but ultimately continue to reload the device list and allow for another Refresh.

Monodevelop 2.9.5 (49347fd0843c7961dad2cee1337f76993b9b567f)
Mono 2.10.9
Mono for Android 4.1.1
Windows 7
Comment 5 PJ 2012-04-18 11:10:37 UTC
360 team is seeing this issue on the latest tested 2.9.5 MD f87f5acaa553514dd7f64ad5ae9f7ef8beae2f81 on *every* attempt to Run without the emulator started. 

Run or debug any solution to open the Select Device dialog
Start an emulator
See bug 2819 (list does not refresh with the active device)
Press Refresh

Expected Result:
List should refresh with the emulator appearing as active and selectable

Actual Result:
List does not refresh and the refresh button becomes disabled

They are able to workaround the issue by starting the emulator, restarting MD, then re-attempting the deploy.

Seen on:

MFA 4.1.1: 4d6c42291ac0a0061ce17a50642a60fe0ccd6244
MD 2.9.5: f87f5acaa553514dd7f64ad5ae9f7ef8beae2f81
Windows 7
Comment 6 Alan McGovern 2012-04-18 11:11:31 UTC
Looking at this now
Comment 7 Alan McGovern 2012-04-18 18:50:06 UTC
Build f87f5acaa553514dd7f64ad5ae9f7ef8beae2f81 should contain the fix. I'll need to test on windows and figure out what is going on there.
Comment 8 Alan McGovern 2012-04-19 16:15:12 UTC
Fixed. It was a race condition in the code which has been there since forever. this particular class of race condition can't happen again, but the code is filled with locks and threads all over the place so please do reopen this bug if you have any other strange issues like the dialog not repopulating correctly.

Commit 86942fcafc227952dd209805b04d9938a1d1e957 in monodevelop contains the fix.