Bug 60771 - Attempting to JIT compile method 'System.Runtime.CompilerServices.Unsafe:Add (byte&,int)' while running in aot-only mode
Summary: Attempting to JIT compile method 'System.Runtime.CompilerServices.Unsafe:Add ...
Alias: None
Product: iOS
Classification: Xamarin
Component: Mono runtime / AOT compiler ()
Version: XI 11.4 (d15-5)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: 15.6
Assignee: Zoltan Varga
Depends on:
Reported: 2017-11-20 13:39 UTC by Christophe C
Modified: 2017-11-29 18:29 UTC (History)
5 users (show)

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

Convert Image<Rgba32> to UIImage (that cause the crash) (1.18 KB, text/plain)
2017-11-20 16:50 UTC, Christophe C

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:

Description Christophe C 2017-11-20 13:39:00 UTC

I got a crash in release mode. Here the stack trace :

Attempting to JIT compile method 'System.Runtime.CompilerServices.Unsafe:Add (byte&,int)' while running in aot-only mode. See https://developer.xamarin.com/guides/ios/advanced_topics/limitations/ for more information.

JpegEncoderCore.ToYCbCr[TPixel] (SixLabors.ImageSharp.PixelAccessor1[TPixel] pixels, SixLabors.ImageSharp.Formats.Jpeg.GolangPort.Components.Encoder.RgbToYCbCrTables* tables, System.Int32 x, System.Int32 y, SixLabors.ImageSharp.Formats.Jpeg.Common.Block8x8F* yBlock, SixLabors.ImageSharp.Formats.Jpeg.Common.Block8x8F* cbBlock, SixLabors.ImageSharp.Formats.Jpeg.Common.Block8x8F* crBlock, SixLabors.ImageSharp.PixelArea1[TPixel] rgbBytes)
(wrapper unknown) System.Object:gsharedvt_in ()
(wrapper unknown) System.Object:gsharedvt_out ()
JpegEncoderCore.Encode420[TPixel] (SixLabors.ImageSharp.PixelAccessor`1[TPixel] pixels)
(wrapper unknown) System.Object:gsharedvt_in ()
(wrapper unknown) System.Object:gsharedvt_out ()

First, I was thinking is was an issue off SixLabors.ImageSharp library, but I posted an issue here : https://github.com/SixLabors/ImageSharp/issues/383 and we have investigated. 

That sounds it's come from System.Runtime.CompilerServices.Unsafe (https://github.com/SixLabors/ImageSharp/issues/383#issuecomment-345668351)

Here my configuration: (the problem is also on the stable release)

=== Visual Studio Enterprise 2017 for Mac (Preview) ===

Version 7.3 Preview (7.3 build 764)
Installation UUID: 9a1cb6a6-0fd6-40ab-a519-eaf8367e9946
	Mono (2017-06/e66d9abbb27) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 504010007

=== NuGet ===


=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
SDK: /usr/local/share/dotnet/sdk/2.0.0/Sdks
SDK Versions:
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.4.1/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

Version: 1.6.0
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Xamarin.Android ===

Version: (Visual Studio Enterprise)
Android SDK: /Users/Christophe/Library/Android/sdk
	Supported Android versions:
		4.1 (API level 16)
		5.1 (API level 22)
		6.0 (API level 23)
		7.0 (API level 24)
		7.1 (API level 25)

SDK Tools Version: 26.1.1
SDK Platform Tools Version: 26.0.1
SDK Build Tools Version: 25.0.3

Java SDK: /usr
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

Android Designer EPL code available here:

=== Xamarin Inspector ===

Version: 1.4.0-beta1
Hash: 2e30f47
Branch: master
Build date: Tue, 14 Nov 2017 22:32:31 GMT
Client compatibility: 1

=== Apple Developer Tools ===

Xcode 9.1 (13532)
Build 9B55

=== Xamarin.iOS ===

Version: (Visual Studio Enterprise)
Hash: c4240f3f
Branch: d15-5
Build date: 2017-11-08 17:28:18-0500

=== Xamarin.Mac ===

Version: (Visual Studio Enterprise)

=== Build Information ===

Release ID: 703000764
Git revision: 54e0a0247ce488f81f6c7806c9bae93307e66c2b
Build date: 2017-11-08 19:22:55-05
Xamarin addins: 97c21309aa29fd2e7df52a5d7426f39a693ea318
Build lane: monodevelop-lion-d15-5

=== Operating System ===

Mac OS X 10.12.6
Darwin 16.7.0 Darwin Kernel Version 16.7.0
    Wed Oct  4 00:17:00 PDT 2017
    root:xnu-3789.71.6~1/RELEASE_X86_64 x86_64

=== Enabled user installed addins ===

Android Signature Tool 2.1.2
AddinMaker 1.4.1
NuGet Package Explorer 0.2
Redth's Addins 1.0.9
Internet of Things (IoT) development (Preview) 7.1

If you have any workaround, please let me know. 
It's extremlly urgent for us.

Kind regards,
Comment 1 Alex Soto [MSFT] 2017-11-20 14:57:49 UTC
Hello Christophe

I see you attached your version information thanks a lot for it, could you please create a reproducible test case for us so we can reproduce this issue?

Thanks in advance!
Comment 2 Christophe C 2017-11-20 16:50:38 UTC
Created attachment 25765 [details]
Convert Image<Rgba32> to UIImage (that cause the crash)
Comment 3 Anton 2017-11-20 23:46:05 UTC
Hi Christophe,

I am the owner of the Jpeg encoder code in ImageSharp. Fingers crossed that (in a hello world project using ImageSharp beta2) the following code is sufficient to reproduce the issue:

using (var image = new Image<Rgba32>(128,128))
using (var stream = new MemoryStream())
    image.Save(stream, ImageFormats.Jpeg);

This comment from Eric Mellino might be also interesting:

Unfortunately I'm not familiar with Xamarin, so I cannot help any more :(
Comment 4 Anton 2017-11-20 23:54:00 UTC
[Actually, I meant to address Alex Soto with my comment.]
Comment 5 Zoltan Varga 2017-11-21 01:10:14 UTC
I can't reproduce using a simple test case above.
Comment 6 Christophe C 2017-11-21 08:03:27 UTC
Hello Zoltan, 

I made a sample project to reproduce de crash.
I tested it and I can reproduce the crash with de sample code of Anton.

Here the Github : https://github.com/Lapinou42/CCSample

Thank you for your feed-back,
Best regards,

- You need to compile the app in Release mode. 
- You need to compile the app on a physical device (mine is iPhone 6S).
Comment 7 Zoltan Varga 2017-11-21 15:13:29 UTC
I can reproduce it using that sample.
Comment 8 Zoltan Varga 2017-11-21 15:30:14 UTC
It only seems to happen in release mode.
Comment 9 Zoltan Varga 2017-11-21 15:31:36 UTC
Also note that that library contains a lot of generics, which the xamarin.ios compiler can't detect, so at runtime, it will fall back to slower code paths, so the performance will be bad, which might be a problem for image processing. I'd suggest using a library with less generics.
Comment 10 Christophe C 2017-11-21 16:23:05 UTC
Thank you Zoltan for your recommandations.
We will check it on our side because we need a library to make some transform on images like crop, rotate, resize, apply filter color, etc. and ImageSharp does the trick.
We noticed it's very slow on both side (iOS / Android) when we need to convert from Image<Rgba32> to native image object.

Hope my sample could help your team to find what's wrong.

Best regards, 
Comment 11 Zoltan Varga 2017-11-22 15:24:21 UTC
Comment 12 Anton 2017-11-22 15:35:36 UTC
Thank you Zoltan!

A question regarding your comment on AOT: "so at runtime, it will fall back to slower code paths":

Does this mean that all the struct insances are gonna be boxed to call the interface methods on generic args? Or something even worse? :)
Comment 13 Zoltan Varga 2017-11-22 17:43:33 UTC
It will fall back to code which is somewhere between compiled code and interpreted code in performance. It won't do extra boxing.
Comment 14 Christophe C 2017-11-22 17:57:56 UTC
Thank you Zoltan for your explanation and
your good job !
Comment 15 Sebastien Pouliot 2017-11-29 16:25:49 UTC
@Zoltan can you back port the fix to 2017-10 ? we'll bump and close it. thanks!
Comment 16 Zoltan Varga 2017-11-29 17:12:48 UTC
Its already done, 2a3c5024f2a047a43b54da55cee023c4c54cc260.
Comment 17 Sebastien Pouliot 2017-11-29 18:29:40 UTC
Missed it, thanks!

We're already bumped over it, so build 5645e3349a164e8ca5ebeb638aa035fb6659d688 can be used to verify the issue is resolved.