Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
All, using Xamarin's default HelloWorld application, I've recreated a case where invoking Quit() on a HandlerThread results in a hung application (clicking the "click me" button results in a change in color and a hung app). Please see the attached sample project. The attached project includes a WorkerThread class that is a subclass of HandlerThread. I found that if I include an OnLooperPrepared() override, the app will hang if I invoke Quit() on the thread. Without the override, the app will not hang. To reproduce this issue, simply uncomment the "#define INCLUDE_LOOPER_OVERRIDE" at the top of MainActivity.cs. This issue seems to have been introduced as a result of upgrading to Xamarin Studio 4.2.1 build 1 and did not occur with 4.2 build 2. Any help that you might be able to provide would be greatly appreciated. Below are details about the version of Xamarin that I'm running.
This happens using Android 4.0.3 and 4.1.1 under VirtualBox and only when debugging the app. Running the app without debugging does not cause the problem. This also does not happen when debugging the app using a real device running 4.0.4 or higher.
I had posted this against your Android forum, but no one responded to it.
Thanks in advance for looking at this.
=== Xamarin Studio ===
Version 4.2.1 (build 1) Installation UUID: 6f7c36db-b063-41d3-aa0d-4184811018e8 Runtime: Mono 3.2.5 ((no/964e8f0) GTK+ 2.24.20 theme: Raleigh GTK# (22.214.171.124) Package version: 302050000
=== Xamarin.Android ===
Version: 4.10.1 (Enterprise Edition) Android SDK: XXX/adt-bundle-mac-x86_64/sdk Supported Android versions: 2.1 (API level 7) 2.2 (API level 8) 2.3 (API level 10) 3.1 (API level 12) 4.0 (API level 14) 4.0.3 (API level 15) 4.1 (API level 16) 4.2 (API level 17) 4.3 (API level 18) Java SDK: /usr java version "1.7.0_17" Java(TM) SE Runtime Environment (build 1.7.0_17-b02) Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
=== Apple Developer Tools ===
=== Xamarin.iOS ===
Version: 126.96.36.199 (Starter Edition) Hash: 23a0827 Branch: Build date: 2013-11-11 16:04:00-0500
=== Xamarin.Mac ===
Xamarin.Mac: Not Installed
=== Build Information ===
Release ID: 402010001 Git revision: 844a84fe0aa0cb5f986d4e3c4807a51487d07845 Build date: 2013-11-13 22:12:16+0000 Xamarin addins: 97e44e4863da6c479427794457637e75b3d22600
=== Operating System ===
Mac OS X 10.8.5 Darwin XXXX 12.5.0 Darwin Kernel Version 12.5.0 Sun Sep 29 13:33:47 PDT 2013 root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64
Created attachment 5601 [details]
sample "hello world" app that demonstrates the problem
When running this app from the debugger, the app will hang when you click the "click here" button.
Has anyone had a chance to look at this issue yet?
Today, we have checked this issue with:
Mac ML 10.8.5
XS 4.2.2(build 2)/XS 4.2.1(build 1)
We are not able to reproduce this issue, attached project "hello world" is running successfully on emulator API 15, app is not hang after clicking on "click me" button multiple times.
Confirmed. I too cannot reproduce this using the android sdk emulator with API 15.
I also have confirmed that this issue is most likely independent of the android version and seems isolated to debugging using VirtualBox. I've been able to reproduce this using VirtualBox running 4.0.3 and 4.2.1. It may be a timing issue, given how fast the VirtualBox implementations are.
At this point, will you do anything further with this, or just consider this case closed?
Please note that the latest alpha version (as of Jan 3, 2013) fixes this problem.
Closing based on customer feedback