Bug 41098 - AOT Bug: 32-bit IOS application crashes at launch after assertion fails.
Summary: AOT Bug: 32-bit IOS application crashes at launch after assertion fails.
Alias: None
Product: iOS
Classification: Xamarin
Component: Mono runtime / AOT compiler ()
Version: 4.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Zoltan Varga
Depends on:
Reported: 2016-05-16 08:55 UTC by Egor Shkorov (Playtika)
Modified: 2017-05-18 09:37 UTC (History)
4 users (show)

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 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 Egor Shkorov (Playtika) 2016-05-16 08:55:59 UTC
So the problem is. I have an application. It compiles and deploys fine. When I try to run the application on a 64-bit devices, such as 5s, 6, 6s and so one, it works fine. But when I start the application on 32-bit device, such as iPhone 5, it crashes with the following message in iOS device log

error: * Assertion at ../../../../../mono/mono/mini/tramp-arm.c:1089, condition `((guint16*)target) [0] == 0xf8df' not met

I have investigated and found that application crashes whenever I even mention (i.e. get typeof(SomeType)) one of my classes that does not use any of Xamarin.IOS features, just a usual code that conforms with PCL profile.

It seems to me that the problems is in generic interfaces limitation that are worked-around by trampolines, but I’m not sure why.

I tried to rewrite the code with less of generic interfaces, but it didn’t seem to work.
The suspect class has the following inheritance hierarchy:

public class StompOverWebSocketsConnection : StompConnection<WebSocketConnectData, WebSocketDisconnectData>, IStompOverWebSocketsConnection

public class StompConnection<TUnderlyingConnectData, TUnderlyingDisconnectData> : IStompConnection<TUnderlyingConnectData, TUnderlyingDisconnectData>, IDisposable

public interface IStompConnection<TUnderlyingConnectData, TUnderlyingDisconnectData : IConnection<StompConnectData<TUnderlyingConnectData>, StompDisconnectData<TUnderlyingDisconnectData>>

public interface IStompOverWebSocketsConnection : IStompConnection<WebSocketConnectData, WebSocketDisconnectData>

public interface IConnection<in TConnectData, in TDisconnectData>
Comment 1 Zoltan Varga 2016-05-16 09:10:07 UTC
Do you have llvm enabled ? Can you check whenever disabling it fixes the problem ?
Comment 2 Egor Shkorov (Playtika) 2016-05-16 10:06:30 UTC
Yes, LLVM optimizations are enabled for our builds.
Comment 3 Egor Shkorov (Playtika) 2016-05-16 10:06:53 UTC
I will check if disabling it helps.
Comment 4 Egor Shkorov (Playtika) 2016-05-16 10:24:36 UTC
It seems that disabling LLVM optimizations does help to avoid this crash, but this is not an option for us.
Comment 5 Zoltan Varga 2016-05-16 10:46:15 UTC
Does keeping llvm enabled, but disabling the 'Use Thumb-2 instructions' option work ?
Comment 6 Egor Shkorov (Playtika) 2016-05-16 10:48:47 UTC
I will check this now. By the way, if I build only ARMv7 build, without ARMv7-64 it also seems to work.
Comment 7 Egor Shkorov (Playtika) 2016-05-16 13:13:32 UTC
By the way, I should have mentioned that this is on Xamarin version
Yes, enabling llvm optimization but turning off thumb instruction set seems to be a workaround for this bug. 

And it also seems that 9.6.* is not affected by this.
Comment 8 Manuel de la Peña [MSFT] 2017-04-10 10:16:51 UTC
@Egor As per your last comment, it seems that the bug was fixed in the latests release, can you confirm if you are ok if we close the bug?
Comment 9 Vincent Dondain [MSFT] 2017-05-18 09:37:31 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and re-open the bug report. Thanks!