Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

[Official] The collected il2cpp forum topic.

Discussion in 'General Discussion' started by RalphH, May 20, 2014.

  1. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    Well, you cannot run IL2CPP in the editor (nobody would want to wait 2 minutes after pressing the play button), so we have to upgrade Mono there at minimum. Standalone platforms aren't getting IL2CPP any time soon yet either.
     
  2. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    I understand the editor side of things, but what I don't understand is why there is talk of the Mono runtime being upgraded when Unity is making the investment and transition into the IL2CPP runtime for the platforms?
     
  3. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    OK, rant time. I know this is offtopic, but I've seen this a number of times and I just can't not say something.

    IL2CPP is not your answer, because the fact of the matter is this: security through obscurity isn't security at all, not even a little bit. Using IL2CPP will not prevent people from packet-sniffing and figuring out how your netcode works. It probably won't even substantially delay how long it takes for people to do so.

    If having access to your client code makes it possible for a player to cheat through the client, in an mmo, you should step back and re-evaluate how you're handling game logic. Ideally, all of your game logic should exist on the server, and your clients are as minimal a terminal to that server as you can get away with. If all of the game logic takes place on the server, then your clients cannot circumvent that game logic even if you were to give them the entire client project in handly .sln format. And if some game logic does exist on the client, then know that it is only a matter of time, even with IL2CPP, before somebody figures that out and breaks your game, so you should be making every effort possible to find ways to move that logic to the server instead.
     
    Meltdown likes this.
  4. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Yep, eventually it will be all platforms. I believe it's available for almost all now. They previously mentioned I think that standalone would be the last platforms to get it.
     
  5. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    Mono runtime is used by the editor. I'm not sure I understand your question. IL2CPP is going to be upgraded to support .NET 4.5 too at the same time.
     
  6. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    @shamsfk

    It's not on our public roadmap yet, but we've had a lot of internal discussion about when to release support for it. So I can't say yet when we will support it, but I think it will be coming in the future at some point.
     
  7. Dave-Carlile

    Dave-Carlile

    Joined:
    Sep 16, 2012
    Posts:
    967
    I would hope that we will always have the option to produce the final output as a .NET app as we do today for standalone. I've been experimenting with IL2CPP and it doesn't seem to support some of the features I need in my project. For modding support I need the ability to load assemblies at runtime and Assembly.LoadFrom isn't supported by IL2CPP. Maybe there is some workaround that IL2CPP does support but I've not yet found one.
     
  8. shamsfk

    shamsfk

    Joined:
    Nov 21, 2014
    Posts:
    307
    Thank you, we'll be waiting with high hopes.
     
  9. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    So at the end of the day will the mono runtime only be used by the editor?
    And each platform build target, will at the end of the day run on IL2CPP?
     
  10. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,081
    Unless you're targeting desktop platforms, in which case no IL2CPP at all.
     
  11. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    Desktop platforms will eventually support IL2CPP so your answer is irrelevant to my question.
     
  12. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    I think the idea is you'll get a choice - you can either make an IL2CPP build OR a full-blown Mono build.
     
    Ostwind likes this.
  13. Ostwind

    Ostwind

    Joined:
    Mar 22, 2011
    Posts:
    2,804
    Yep IL2CPP is AOT so it won't be an option to everyone depending of the project and required features.
     
  14. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    We'll probably not remove Mono option for standalone platforms - there isn't much cost to it as it already works on the same platform in the editor. Also, as other people mentioned, IL2CPP has some differences to Mono and cannot support some scenarios that people are using for their PC games. We will definitely increasingly go towards IL2CPP being the scripting backend for other players, though, I can't tell you the timelines. For instance, I know for a fact (since I'm personally working on it :D) that we're aiming to get rid of .NET scripting backend on Windows Store, and we'd like to do it sooner than later.
     
    Meltdown and Dave-Carlile like this.
  15. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Ugh.... it then becomes harder to debug. I like having the .NET Scripting Backend on Windows Store since it eventually gets compiled by .NET Native anyway. :(
     
    MV10 likes this.
  16. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    Yeah, but the cost of it is the fact that totally different .NET class libraries, which makes it a pain in the ass to port your code if you used non-basic .NET features. Last time I checked, .NET scripting backend misses over 9000 types (no pun intended) that are available on our .NET 3.5 profile. That number is only going to increase once we move to .NET 4.6. Honestly, I think that it's been the biggest issue for this platform so far preventing people to port their games to it.

    There's also the issue of it being external to us, so we by definition cannot fix some of the bugs that people encounter. It being the odd ball with it's own Unity's serialization reimplementation, interop layer and whole bunch of hardly maintainable code is a major blocker preventing us from doing certain stuff we'd like with the public API. It has incredibly huge maintenance cost internally. Often new scripting features which are easy to implement for Mono/IL2CPP scripting backends need total reimplementation from scratch for .NET, and it even sometimes ends up not supporting every detail of a new feature (JSON serialization in 5.3 is a good example of that). Just yesterday I spent the whole day implementing a feature for .NET scripting backend (targeting 5.6) that was a 2 liner on Mono/IL2CPP path. Here's a picture that we use internally to accurately represent how .NET scripting backend is stitched together in Unity:

    http://i.imgur.com/LpzSS9k.gif
     
  17. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    THis, so much. The Windows Store's version of the .NET API is a mess of incompatibilities that make supporting it a massive pain in the ass and almost not even worth it IMHO.
     
  18. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    +103983839 to this.

    I ported games from Android/iOS to Windows Store for 18 months in a full time job, and I wanted to kill myself.
     
  19. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
  20. MV10

    MV10

    Joined:
    Nov 6, 2015
    Posts:
    1,889
  21. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
  22. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Depends, you have the 4.6 editor beta out... if the profile gets updated to 4.6 then NetStandard 2.0 and Framework 4.6 I believe are cross compatible.
     
  23. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    I had the impression that .NET framework 4.6 is a superset. They're definitely not going to bring full .NET Framework into .NET Core.
     
  24. MV10

    MV10

    Joined:
    Nov 6, 2015
    Posts:
    1,889
    The way I've interpreted it, I was under the impression .NET Framework "should be" a superset relative to Core only where it relies upon Windows-specific systems. One example is crypto -- Core has a different classes that are cross-platform. I end up with junk like this in my code as a result:

    Code (csharp):
    1.             #if NET35
    2.                 SHA512Managed hasher = new SHA512Managed();
    3.             #elif NETSTANDARD1_6
    4.                 HashAlgorithm hasher = SHA512.Create();
    5.             #endif
     
    Dustin-Horne likes this.
  25. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Definitely, but nearly all of it will be available. NetStandard defines a set of APIs essentially. .NET Core is still laregly the .NET Framework but split into modular packages and rewritten for better performance.
     
  26. Doddler

    Doddler

    Joined:
    Jul 12, 2011
    Posts:
    269
    The state of IL disassembly is basically to the point where a person can pull out nearly compile-able code with very little effort. Though IL2CPP interests me more for performance reasons, I see the point of security being less about making it harder for users to change your code or find exploits, and more about making it so people can't just transplant usable assets and code from my game into working unity projects.

    This is especially true for asset sellers (for non editor assets), since people can and do pull those assets out of projects that use them. WebGL has made this a bit better since you can't get usable code out of it, there was a point where you might not want to put up a webplayer demo of your asset since it could be ripped straight from the demo.

    Personally I want to see IL2CPP for desktop platforms, mostly for the improved performance it might offer. It sounds like that's still a long way out though...
     
    mischa2k and crudeMe like this.
  27. AlanMattano

    AlanMattano

    Joined:
    Aug 22, 2013
    Posts:
    1,501
    @Tautvydas-Zilys IL2CPP is in the manual for WindowsStore
    Standalone platforms aren't getting IL2CPP any time soon yet ? This IL2CPP remembers me the UI :p Probably there is a lot of work involve.

    Unity needs RSS announcing each new feature when is available. Or Improve release notes info linking each improvement to a blog, a forum thread or video tutorial. Because I loose a lot of time researching what is available, what is not and what each improvement means in practical, sometimes with no result.

    I love the idea that my game is running in C++ while programming in a simple language (C#) !
     
    Last edited: Oct 21, 2016
  28. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    Not really, but it needs somebody to actually work on it. And that doesn't happen because there are more important things to do.
     
  29. krassemanne

    krassemanne

    Joined:
    Jun 27, 2015
    Posts:
    8
    Hello, I hope this question hasn't been answered already:

    Is it allowed to use the output from IL2CPP in other non-Unity C++ projects? I know that there are other C# to C++ translators, just checking if using IL2CPP is allowed.

    Thanks for your awesome work with this!
     
  30. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    I don't think that we have any restrictions on how you can use IL2CPP, but we can't offer support for usage outside of Unity.
     
    krassemanne likes this.
  31. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    @krassemanne Maybe I should walk back a bit on my statement. I guess that the Unity EULA covers all binaries shipped with Unity, not just Unity itself, so you really can't use il2cpp.exe for things outside of Unity without violating the EULA. Sorry for the confusion.
     
  32. krassemanne

    krassemanne

    Joined:
    Jun 27, 2015
    Posts:
    8
    Ok, thanks for quick answer. I'll look for other solutions then.
     
  33. GreatNimbus

    GreatNimbus

    Joined:
    Jul 13, 2013
    Posts:
    13
    I'm not sure if others are having the same issue, but i recently tried to switch over to IL2CPP but i get three errors about IL2CPP.exe not running properly...

    Unity 5.5.0
    Building from: Mac 10.12.1
    Building platform: Android

    From what i can see it looks like it's trying to run a .exe? perhaps the .dmg is missing?

    I've attached the three errors.
     

    Attached Files:

    Last edited: Dec 19, 2016
  34. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,589
    Il2Cpp brings up some points that make it hard to work with. Here are a few points off the top of my head.

    "Converting managed assemblies to C++" takes about 15 minutes in our project and that's only one part of the whole build process. It takes another coffee break when compiling/linking those generated source files. Some sort of incremental "Converting managed assemblies to C++" feature would be very welcome.

    I used to use Mono for development builds, due to the faster turnaround times when testing on a device. At some point in the project, we ran in to different bugs with different runtime backends. Our game does not work with both. We had to commit to one runtime backend and then workaround all its bugs. The choice was Il2Cpp, because that's what the master build must use. Unfortunately, this decision slowed down every single person on the team who needs to do a build (build-servers affected too).

    The C++ code does not look like how any person would write that, thus makes it hard to read and debug.
    This becomes a problem when platform specific bugs occur. I looked for hours at what used to be a very simple co-routine in C#, because all the C++ code was split across so many different places what made it really hard to follow. The co-routine example is an extreme, but it applies to pretty much every code generated. I wished the C# structure could be better preserved.

    The generated .cpp files can be gigantic. When the game crashes and Xcode opens/displays the assembly code of such .cpp file (the .s file), Xcode often turns unresponsive because the file seems to be too big.

    The lack of Il2Cpp for desktop platforms. I wanted to fix/extend Unity's Memory Profiler from bit-bucket, but it requires Il2Cpp. Building for iOS/Android and deploying on a device to work on that tool seemed to call for too much trouble and I simply dropped the idea.
     
  35. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    A .dmg is a disk image, used for distributing files, and not something Unity uses for anything. The exe is running but ran into an unhandled exception for some reason.

    --Eric
     
  36. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    What hardware are you on? 15 minutes sounds excessive - I bet you're hitting some sort of bottleneck that can be solved. I don't think I've seen conversion times longer than 2-3 minutes myself. I've got a few tips to greatly reduce IL2CPP build times (it's included in 5.6 documentation - just copy pasting it here):

    1. Use incremental building. This makes the C++ compiler recompile only the files that changed since the last build. To use it, just build your project to a location you previously built it last time (without deleting the actual target folder).

    2. Exclude project and target build folders from anti-malware software scans. We’ve seen a build time improvement of 2-3x after disabling Windows Defender on a fresh Windows 10 installation.

    3. Have your project and target build folder reside on an SSD. Converting IL code to C++ and compiling is it a heavy task for your storage device, so using fast storage naturally makes it much faster.

    We have this semi-addressed for 5.6. Check this out: http://i.imgur.com/KKrJgEs.png

    You can deploy to Windows desktop through Windows Store target and use memory profiler that way.
     
    Peter77 and mh114 like this.
  37. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,589
    iMac Intel Core i7 3,5 GHz 32 GB; NVIDIA GeForce GTX 780M; 4096 MB; Mac OS X 10 (and windows 10 on another partition).
    I submitted Case 839040 with that machine a while ago. I believe the bug-reporter automatically collects related system info, in case more info is needed.


    We have a customized build-pipeline that calls BuildPipeline.BuildPlayer with the same output folder always, no files are deleted from that folder. We do not use the Build or Build & Run buttons under the File menu.

    Is there an option to enable this maybe? We use the following BuildOption to make a debug build:
    Development | AllowDebugging | SymlinkLibraries

    As I'm now reading through the documentation, I found AcceptExternalModificationsToPlayer which seems to be responsible to make incremental builds work in Xcode. I'm going to give this option a try.

    As I understand the AcceptExternalModificationsToPlayer documentation, it helps to speed up compiling the C++ code. "Converting managed assemblies to C++" is still going to do a full conversion, right?


    I believe all our machines in the office feature a SDD, but I can hardly image that the project is excluded from anti-virus software. I'm going to try this out too.


    I guess the comments with the C# code are new? That might help a little, but the code is still hard to follow.

    Perhaps better names than L_0 to L_15 would already make that code easier to follow. Tools such as ILSpy or Reflector are somehow able to guess local variable names that are pretty useful.

    Class and method names for example are also hard to follow for me. I guess due to their names being "mangled", such as BinaryFormatter_Tests_U3CCanSerializeDictionaryAndBackU3Em_62_m65699066_MethodInfo_var. It requires a lot of effort to see what's going on.


    Good point!

    Thanks a lot for your reply! Hopefully this already solved some of the issues on our side.
     
  38. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    That's correct. Still, I have a hard time grasping the fact that it takes 15 minutes to "Convert managed assemblies to C++". I'd double check on that antivirus software theory. BTW does it also take that long on your windows machine?

    Yes. Personally, it made it much easier for me to read and debug generated C++ code after making this feature. Your mileage may wary :)

    Full unmangled class/method names are emitted just above each method definition/declaration too.
     
  39. GreatNimbus

    GreatNimbus

    Joined:
    Jul 13, 2013
    Posts:
    13
    Thanks for the reply. Pretty unfortunate that even though my projects builds just fine normally, IL2CPP seems to randomly not work... Guess i'll have to wait for unity's next update :/
     
  40. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    Don't do that. Instead let us know about the issue by reporting a bug with a repro project. Posting on forum about it is not really enough.
     
  41. larku

    larku

    Joined:
    Mar 14, 2013
    Posts:
    1,422
    Building using IL2CPP for Android on my Windows machine takes 15 min or more for me with even a reasonably small project.

    My machine is certainly not a powerhouse:

    Windows 7
    Intel Core 2 Due E7600 @ 3.06GHz (27" 2009 iMac running Windows 7 on hardware (ie, no OSX installed or anything))
    8 GB Ram
    850 evo SSD

    IL2CPP builds are certainly a "Get a cup of coffee, empty the dishwasher, chop some vegies , grab another cuppa, then come back" type episode. I tend to use it only for doing release builds due to this.
     
  42. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    @larku Yeah that CPU is super slow and I can see it taking longer on it. Though, keep in mind that building for Android with IL2CPP not only converts, but also compiles the generated C++ code. Make sure that in player settings you select "ARMv7" only target architecture, or it will compile code twice: once for ARM and once for x86.
     
  43. larku

    larku

    Joined:
    Mar 14, 2013
    Posts:
    1,422
    Yeah, I do build fat binaries for release, so I must wear that pain :)

    I have an identical machine also running OSX for iOS builds and it is significantly faster to do an IL2CPP build (including the Xcode compilation step) - I assume this is really just showing the difference in speed between the two compilers!

    But yes, my antiquated hardware is the issue - I just really like those 27" iMac displays.
     
  44. RaventurnPatrick

    RaventurnPatrick

    Joined:
    Aug 9, 2011
    Posts:
    248
    When building for IOS with il2cpp, are the "aot compilation options" still applied and why? Do you still use the mono-aot compiler before il2cpp?

    Backstory (for those interested):
    We built our game with Unity 5.6.1f to ios (cloudbuild) and got some crashes containing "get_numerous_trampoline" and later a sigsev - so I assumed we ran out of trampolines (as ToList() / ToArray Linq calls were also included in the stack trace)
    After adding "nimt-trampolines=512" to the "aot compilation options" the ios app works again without crashes (however I cannot see this parameter being passed in the cloud build log for some reason?)

    I just want to be sure that unity somehow uses that setting for ios.. so it's not "randomly" working again (and the bug still exists)​
     
    Last edited: May 17, 2017
  45. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    IL2CPP doesn't use mono trampolines at all. That option is definitely not respected in IL2CPP builds. Do you have the full stacktrace?
     
  46. RaventurnPatrick

    RaventurnPatrick

    Joined:
    Aug 9, 2011
    Posts:
    248
    Yes however we also changed the scripting backend from "Mono2x" to "il2cpp" in the Editor for the ios target (however I thought Unity now always uses il2cpp for ios cloudbuild)

    Code (CSharp):
    1. Hardware Model:      iPhone7,2
    2. Process:             burst [256]
    3. Path:                /private/var/containers/Bundle/Application/905F4455-C9B4-442D-BBE4-70E9933505C5/burst.app/burst
    4. Identifier:          com.bigbang.burst
    5. Version:             0 (1.0)
    6. Code Type:           ARM (Native)
    7. Role:                Foreground
    8. Parent Process:      launchd [1]
    9. Coalition:           com.bigbang.burst [391]
    10.  
    11.  
    12. Date/Time:           2017-05-17 20:35:54.7560 +0200
    13. Launch Time:         2017-05-17 20:34:41.9117 +0200
    14. OS Version:          iPhone OS 10.3.2 (14F89)
    15. Report Version:      104
    16.  
    17. Exception Type:  EXC_CRASH (SIGABRT)
    18. Exception Codes: 0x0000000000000000, 0x0000000000000000
    19. Exception Note:  EXC_CORPSE_NOTIFY
    20. Triggered by Thread:  0
    21.  
    22. Filtered syslog:
    23. None found
    24.  
    25. Thread 0 Crashed:
    26. 0   libsystem_kernel.dylib            0x1d355acc __pthread_kill + 8
    27. 1   libsystem_c.dylib                 0x1d2ea95b abort + 109
    28. 2   burst                             0x032bec88 print_stack_frame + 0
    29. 3   burst                             0x032acd84 mono_sigsegv_signal_handler + 256
    30. 4   libsystem_platform.dylib          0x1d408259 _sigtramp + 25
    31. 5   libsystem_pthread.dylib           0x1d40e087 pthread_kill + 63
    32. 6   libsystem_c.dylib                 0x1d2bb85f raise + 17
    33. 7   burst                             0x033a9824 g_logv + 160
    34. 8   burst                             0x033a9898 g_log + 32
    35. 9   burst                             0x032bab74 get_numerous_trampoline + 360
    36. 10  burst                             0x032bae54 mono_aot_get_imt_thunk + 64
    37. 11  burst                             0x03356b6c initialize_imt_slot + 128
    38. 12  burst                             0x0335022c build_imt_slots + 704
    39. 13  burst                             0x0334fef4 mono_vtable_build_imt_slot + 256
    40. 14  burst                             0x032c02f8 mono_convert_imt_slot_to_vtable_slot + 236
    41. 15  burst                             0x032bf720 mono_magic_trampoline + 644
    42. 16  burst                             0x02242fa8 method_order_end + 120
    43. 17  burst                             0x02178df4 m_System_Collections_Generic_List_1_AddEnumerable_System_Collections_Generic_IEnumerable_1_T + 228
    44. 18  burst                             0x02177fa8 m_System_Collections_Generic_List_1__ctor_System_Collections_Generic_IEnumerable_1_T + 152
    45. 19  burst                             0x00c6c8b4 m_System_Linq_Enumerable_ToList_TSource_System_Collections_Generic_IEnumerable_1_TSource + 64
    46. 20  burst                             0x003e3754 m_Burst_Logic_Behaviours_Followers_BattleZone_Start + 580
    47. 21  burst                             0x02196cd8 m_wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 204
    48. 22  burst                             0x032af3e4 mono_jit_runtime_invoke + 2156
    49. 23  burst                             0x0334d6f4 mono_runtime_invoke + 136
    50. 24  burst                             0x029ebc8c scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool) (ScriptingApi_Mono.cpp:486)
    51. 25  burst                             0x029e6e88 ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool) (ScriptingInvocation.cpp:303)
    52. 26  burst                             0x02c90f50 MonoBehaviour::InvokeMethodOrCoroutineChecked(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingExceptionPtr*) (MonoBehaviour.cpp:800)
    53. 27  burst                             0x02c91500 MonoBehaviour::InvokeMethodOrCoroutineChecked(ScriptingMethodPtr, ScriptingObjectPtr) (MonoBehaviour.cpp:881)
    54. 28  burst                             0x02c90040 MonoBehaviour::DelayedStartCall(Object*, void*) (MonoBehaviour.cpp:1236)
    55. 29  burst                             0x02649aac DelayedCallManager::Update(int) (CallDelayed.cpp:179)
    56. 30  burst                             0x0283ca98 PlayerLoop() (PlayerLoop.cpp:122)
    57. 31  burst                             0x02d9566c UnityPlayerLoopImpl(bool) (LibEntryPoint.mm:223)
    58. 32  burst                             0x0005be04 UnityRepaint (UnityAppController+Rendering.mm:271)
    59. 33  burst                             0x0005bcec -[UnityAppController(Rendering) repaintDisplayLink] (UnityAppController+Rendering.mm:78)
    60. 34  QuartzCore                        0x2091f9f1 CA::Display::DisplayLinkItem::dispatch(unsigned long long) + 113
    61. 35  QuartzCore                        0x2091f839 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 609
    62. 36  IOMobileFramebuffer               0x1fdbe1bf IOMobileFramebufferVsyncNotifyFunc + 89
    63. 37  IOKit                             0x1ddd8a7f IODispatchCalloutFromCFMessage + 237
    64. 38  CoreFoundation                    0x1db30c19 __CFMachPortPerform + 129
    65. 39  CoreFoundation                    0x1db4465f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 35
    66. 40  CoreFoundation                    0x1db43ebd __CFRunLoopDoSource1 + 339
    67. 41  CoreFoundation                    0x1db41eab __CFRunLoopRun + 995
    68. 42  CoreFoundation                    0x1da951af CFRunLoopRunSpecific + 471
    69. 43  CoreFoundation                    0x1da94fd1 CFRunLoopRunInMode + 105
    70. 44  GraphicsServices                  0x1f23fb41 GSEventRunModal + 81
    71. 45  UIKit                             0x22e16e13 UIApplicationMain + 151
    72. 46  burst                             0x0004f04c main (main.mm:35)
    73. 47  libdyld.dylib                     0x1d2824eb start + 3
    This is the stacktrace of the crashed thread (this version of the app crashed very regularly on many many different places - however always some kind of linq method was involved)
     
  47. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    That stacktrace is definitely from a Mono and not an IL2CPP build.
     
  48. RaventurnPatrick

    RaventurnPatrick

    Joined:
    Aug 9, 2011
    Posts:
    248
    I see. So I assume that unity still uses Mono AOT in 5.6.1f (and cloudbuild) when not explicitly switching to il2cpp in the Player Settings? (Note: This crash occured in an app built in the unity cloud)

    I did also find out with a default project (no changes to the ios platform) Unity Cloud Build defines this:
    -define:ENABLE_MONO (in the log)

    while when setting the scripting backend to il2cpp this is defined instead:
    -define:ENABLE_IL2CPP

    So the info here: https://docs.unity3d.com/Manual/IL2CPP.html
    *IL2CPP is the only scripting back end available when building for iOS and WebGL.
    Is wrong atm?
     
    Last edited: May 18, 2017
  49. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    I don't think cloud build changes your project settings for you. However, while building with Mono works, I don't think you can ship with it to the app store.
     
  50. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Apparently it still allows building with Mono but don't do that. You'll need IL2CPP to support 64-bit builds on iOS so the Apple Store won't even approve builds using the Mono backend. That being said, it is sometimes still useful to build with both because you may find something that works with the Mono backend and not IL2CPP in which case it would (most likely) be an IL2CPP bug, so having both has been historically useful, but IL2CPP has gotten very stable so 99% of the time you should ignore the Mono backend option and just use IL2CPP. However, I do find the stripping on IL2CPP to sometimes be far too aggressive so sometimes it again is still useful to build with Mono with stripping disabled to help determine if that is an issue.