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.
Created attachment 9402 [details]
The attached sample demonstrates the issues. Monitor.TryEnter returns false when it is expected to return true.
**Steps to Reproduce:**
1. Run the attached sample on an iOS simulator
2. Press the "Start" button.
3. Wait ~30 seconds until there is an "Error enter" log. The red number at the bottom will also increase.
Monitor.TryEnter returns false
Monitor.TryEnter should always be returning true in this sample.
This is the expected logic
- Do work for 500 ms
- wait 1000 ms
- Repeat until canceled
**Build Date & Platform:**
We have checked and getting same behavior as mentioned in bug description , there is an "Error enter" log and then red number at the bottom will also increase. Screencast: http://www.screencast.com/t/M6q8uS7ne
Application Output: https://gist.github.com/RamChBachkheti/89e150b895af5b968185
Build Output: https://gist.github.com/RamChBachkheti/25839dd380fefacfb6b8
IDE Log: https://gist.github.com/RamChBachkheti/69c5360960bcdc5b383b
Version 5.7.1 (build 13)
Installation UUID: 0b7eaebc-a0ed-4b58-81df-91e378cad28c
Mono 3.12.0 ((detached/a813491)
GTK+ 2.24.23 (Raleigh theme)
Package version: 312000068
Version: 184.108.40.206 (Trial Edition)
Android SDK: /Users/Admin_Mac/Desktop/Anddk/android-sdk-macosx
Supported Android versions:
2.3 (API level 10)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
4.4.87 (API level 20)
5.0 (API level 21)
Java SDK: /usr
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
Apple Developer Tools
Xcode 6.1.1 (6611)
Version: 220.127.116.11 (Business Edition)
Build date: 2015-01-15 15:06:20-0500
Version: 18.104.22.168 (Business Edition)
Release ID: 507010013
Git revision: 8e357d6be321e716f361ebc9591e4cee7f217c21
Build date: 2015-01-15 14:23:22-05
Xamarin addins: a6842a7727f64e956f942b8160f7835c9d9076a4
Mac OS X 10.10.2
Darwin Admin-Macs-Mac-mini.local 14.1.0 Darwin Kernel Version 14.1.0
Thu Nov 13 18:36:56 PST 2014
That's seems to be a runtime/BCL issue (the only iOS parts are the UI)
-> Rodrigo (for assigning it to the right person).
This code is broken, you cannot exit a monitor on a different thread than the one that acquires it.
It's failing because it's never unlocking and you're overflowing the recursion counter.
Rodrigo, can you please explain why the thread is different?
Sure, there's an await in between locking and unlocking. This cause the context to switch to another thread.
Context switches during await only if task is configured to do so.
From what I know await returns on the same thread as it was before, that is the idea.
From this article's presentation:
“Await task” uses the sync context
1. It captures the current SyncContext before awaiting.
2. Upon task completion, it calls SyncContext.Post() to resume “where you were before”
Also (I know it's not argument, but) on native .net we have never been able to reproduce problem with the exactly same code.