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.
Test case in https://github.com/anakryiko/mono-jit-crash-repro
Reproduction of problems with Mono JIT crashing.
To run reproduce, compile the solution and run **run.sh** script which will start the binary in a loop until the program crashes. It usually doesn't take long for crash or segmentation fault to occur, though it can take up to few thousands runs.
There are two classes that reproduces two bugs:
* **ReproJitCrash.cs** reproduces JIT crash most of the times. Rarely it also causes segmentation fault without any stack traces.
* **ReproSegFault.cs** reproduces segmenation fault with no stack trace (as mentioned previously).
The only difference between those two cases is in using *struct* vs *class* with **using** statement (see LockReleaserStruct/LockReleaserClass).
Also, it seems essential to have Monitor.Enter/Monitor.Exit, without them it's not reproducible (or at least I didn't have patience to wait for crash to happen).
Hope that helps to identify and fix the problem.
Zoltan, can you give it a spin? It's a crash on the amd64 JIT.
What mono version/architecture/os is this ?
Also, for the crashes with stack traces, what is the stack trace ?
Mono: 3.0.1 (no/301b6c6) (though we also tried on different revisions of 3.x version), amd64
OS: Ubuntu 12.04 LTS (both server and non-server editions)
As for stack trace, please, see ReproJitCrash.cs at the bottom of the file there is full stack trace in comments.
This is due to a race in computing class->instance_size, mono_class_instance_size () checks for size_inited, but that is set much earlier than instance_size.
Can this be somehow fixed? It causes a lot of crashes for us.
It will be fixed. A workaround is to somehow avoid JITting the same method from multiple threads, like executing it once, and only later executing it concurrently.
Fixed in master (5d08f48763b83cfd00adb9444a7bbb5306a89815)/2.10 (f7f96f96af9d5eee263a6f4522952f548ed5c2fd).
Thanks for the report.