Bug 8905 - JIT crashes and segfaults
Summary: JIT crashes and segfaults
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: JIT ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-12-12 11:04 UTC by Rodrigo Kumpera
Modified: 2013-01-07 03:30 UTC (History)
5 users (show)

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

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

Description Rodrigo Kumpera 2012-12-12 11:04:51 UTC
Test case in https://github.com/anakryiko/mono-jit-crash-repro

From readme:

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.
Comment 1 Rodrigo Kumpera 2012-12-12 11:11:35 UTC
Zoltan, can you give it a spin? It's a crash on the amd64 JIT.
Comment 2 Zoltan Varga 2012-12-16 19:21:22 UTC
What mono version/architecture/os is this ?
Comment 3 Zoltan Varga 2012-12-16 19:21:56 UTC
Also, for the crashes with stack traces, what is the stack trace ?
Comment 4 Andrii Nakryiko 2012-12-17 04:13:19 UTC
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.
Comment 5 Zoltan Varga 2012-12-17 17:17:06 UTC
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.
Comment 6 Andrii Nakryiko 2012-12-19 10:37:31 UTC
Zoltan,

Can this be somehow fixed? It causes a lot of crashes for us.
Comment 7 Zoltan Varga 2012-12-20 00:02:47 UTC
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.
Comment 8 Zoltan Varga 2013-01-07 03:30:26 UTC
Fixed in master (5d08f48763b83cfd00adb9444a7bbb5306a89815)/2.10 (f7f96f96af9d5eee263a6f4522952f548ed5c2fd).
Thanks for the report.