Bug 21270 - Deadlock during init of class <StartupCode$ConsoleApplication1>.$Program..cctor
Summary: Deadlock during init of class <StartupCode$ConsoleApplication1>.$Program..cctor
Alias: None
Product: Runtime
Classification: Mono
Component: JIT ()
Version: 3.4.0
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2014-07-11 17:12 UTC by Clay Mayers
Modified: 2014-07-13 11:01 UTC (History)
3 users (show)

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

Source code and backtrace from SO question 22778028 (3.32 KB, application/zip)
2014-07-11 17:12 UTC, Clay Mayers

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 GitHub or Developer Community 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 Clay Mayers 2014-07-11 17:12:04 UTC
Created attachment 7342 [details]
Source code and backtrace from SO question 22778028

The program in this stackoverflow question on F# - http://stackoverflow.com/questions/22778028/how-to-execute-a-function-that-creates-a-lot-of-objects-in-parallel deadlocks every time on my Mac for the Release build.  I have not seen it do so for a Debug build.

I instrumented mono/metadata/object.c's mono_runtime_class_init_full() to know the main thread is initing/invoking the method <StartupCode$ConsoleApplication1>.$Program..cctor and two other threads are waiting for the init to complete.  Attached is the code I'm using and an lldb stack trace post deadlock.
Comment 1 Zoltan Varga 2014-07-12 16:49:53 UTC
Does this work under windows on .net ?
What happens is that the 'assessments' becomes a static field of the $Program class, and it is initialized using some parallel api in the static ctor, and the main thread is blocked waiting for some parallel threads to finish, and the parallel threads are blocked for the static ctor to finish. So I'm not sure this is a mono bug.
Comment 2 Clay Mayers 2014-07-12 19:41:26 UTC
Windows gets further (the main thread seems to run through its partition of the map, whereas with mono the main thread doesn't seem to do any work) but then deadlocks in essentially the same way.  The main thread blocked on a managed lock and two worker threads blocked on a critical section trying to init a class.

I found this in the CLI spec Partition II: Races and deadlocks
In addition to the type initialization guarantees specified in §, the CLI shall ensure two further guarantees for code that is called from a type initializer:
1. Static variables of a type are in a known state prior to any access whatsoever.
2. Type initialization alone shall not create a deadlock unless some code called from a type initializer (directly or indirectly) explicitly invokes blocking operations.

I think item 2 says the fsharp compiler was asking for deadlock by placing a blocking operation in a static constructor and so this is not a mono bug.  

Sorry for the mistake - I ran 'call mono_locks_dump (0)' in lldb and it returned no locks so I assumed managed code wasn't involved.
Comment 3 Zoltan Varga 2014-07-13 11:01:51 UTC