Bug 26174 - Monitor.TryEnter fails to enter unexpectantly
Summary: Monitor.TryEnter fails to enter unexpectantly
Status: RESOLVED INVALID
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: XI 8.6.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Rodrigo Kumpera
URL:
Depends on:
Blocks:
 
Reported: 2015-01-19 16:22 UTC by John Miller [MSFT]
Modified: 2015-01-26 13:38 UTC (History)
4 users (show)

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


Attachments
Test Case (19.26 KB, application/zip)
2015-01-19 16:22 UTC, John Miller [MSFT]
Details


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:
Status:
RESOLVED INVALID

Description John Miller [MSFT] 2015-01-19 16:22:35 UTC
Created attachment 9402 [details]
Test Case

**Overview:**

   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. 

**Actual Results:**

   Monitor.TryEnter returns false

**Expected Results:**

   Monitor.TryEnter should always be returning true in this sample. 
   This is the expected logic
   - TryEnter
   - Do work for 500 ms
   - Exit
   - wait 1000 ms
   - Repeat until canceled

**Build Date & Platform:**

   XI 8.6
   Mono 3.12
Comment 1 Prashant manu 2015-01-20 02:39:52 UTC
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

Supplement Info:
Application Output: https://gist.github.com/RamChBachkheti/89e150b895af5b968185
Build Output: https://gist.github.com/RamChBachkheti/25839dd380fefacfb6b8
IDE Log: https://gist.github.com/RamChBachkheti/69c5360960bcdc5b383b

Environment Info:
Xamarin Studio
Version 5.7.1 (build 13)
Installation UUID: 0b7eaebc-a0ed-4b58-81df-91e378cad28c
Runtime:
	Mono 3.12.0 ((detached/a813491)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 312000068

Xamarin.Android
Version: 5.0.0.16 (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)
Build 6A2008a

Xamarin.iOS
Version: 8.6.1.6 (Business Edition)
Hash: dd1b996
Branch: 
Build date: 2015-01-15 15:06:20-0500

Xamarin.Mac
Version: 1.10.0.18 (Business Edition)

Build Information
Release ID: 507010013
Git revision: 8e357d6be321e716f361ebc9591e4cee7f217c21
Build date: 2015-01-15 14:23:22-05
Xamarin addins: a6842a7727f64e956f942b8160f7835c9d9076a4

Operating System
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
    root:xnu-2782.10.65~2/RELEASE_X86_64 x86_64
Comment 2 Sebastien Pouliot 2015-01-20 10:53:32 UTC
That's seems to be a runtime/BCL issue (the only iOS parts are the UI) 
-> Rodrigo (for assigning it to the right person).
Comment 3 Rodrigo Kumpera 2015-01-20 11:17:03 UTC
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.
Comment 4 alex 2015-01-23 15:16:23 UTC
Rodrigo, can you please explain why the thread is different?
Comment 5 Rodrigo Kumpera 2015-01-26 10:09:25 UTC
Sure, there's an await in between locking and unlocking. This cause the context to switch to another thread.
Comment 6 alex 2015-01-26 13:11:24 UTC
Context switches during await only if task is configured to do so.
.ConfigureAwait(false);
From what I know await returns on the same thread as it was before, that is the idea.
Comment 7 alex 2015-01-26 13:38:47 UTC
From this article's presentation:
http://blogs.msdn.com/b/lucian/archive/2013/11/23/talk-mvp-summit-async-best-practices.aspx

“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.