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
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.
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.
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.
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:
10.5.3.3 Races and deadlocks
In addition to the type initialization guarantees specified in §10.5.3.1, 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.