IL2CPP - Fast but no Exceptions vs. Slow and Safe

Hi,

Is there any difference in the IL2CPP generated code when setting Script Call Optimization to "Fast but no Exceptions" vs. when it is set to "Slow and Safe" ?

We tried doing a directory comparison of the generated code for our game and it did not show any difference (except for a timestamp in a comment). So obviously that indicates that there is no difference, but it would be good to get it confirmed, since the accepted "rule" for the Mono 2.x backend was that you should always run with "Fast but no Exceptions".

We are aware of the difference introduced in 4.6.7p2 whereby the old behaviour of crashing the engine in case of an unhandled exception was introduced for IL2CPP code (as it should be). Is this actually the only difference between Fast but no Exceptions vs Slow and Safe when using IL2CPP ?

If it is the case that there is no difference in the code generated, then it must also be the case that there is no longer any constant overhead of using exceptions within an iOS project - currently the documentation for iOS player settings (http://docs.unity3d.com/Manual/class-PlayerSettingsiOS.html) indicates that you should not use any exceptions on iOS - maybe this statement needs a bit more nuance when using the IL2CPP backend ?

I hope somebody at Unity would be kind enough to clear this up.

Best regards,
Morten Nielsen

 

@JoshPeterson

Thanks for confirming. Now to the real problem and why we are concerned about this

We sometimes experience unhandled exceptions where we receive an empty StackTrace on iOS (using Unity 4.6.6p4). Our exception handler looks like this:

Code (CSharp):

1. public void OnHandleUnresolvedException(object sender, System.UnhandledExceptionEventArgs args){
2.     if(args == null || args.ExceptionObject == null)
3.     {
4.         return;
5.     }
6.  
7.     if(args.ExceptionObject.GetType() == typeof(System.Exception))
8.     {
9.         System.Exception e    = (System.Exception)args.ExceptionObject;
10.         HandleException(e.Source, e.StackTrace); //Write the stack trace to disk and try to send it to HockeyApp
11.     }
12. }

On iOS, e.StackTrace is sometimes empty. We never see this on Android, which uses the exact same code. We are not able to reproduce these empty stack traces ourselves, but we receive a fair amount every day in our HockeyApp account.

To try and work around this, we started investigating not installing an unhandled exception handler (like in the pre-IL2CPP days) on iOS and instead rely on the native stack traces. Unfortunately the produced stack traces are not useful, since they are missing the most critical part of the stack. This was done using Unity 4.6.8p3.

An example should illustrate the problem. This is is the stacktrace where the exception is raised inside NullCheck:


This is the stacktrace we are left with when we reach CrashedCheckBellowForHintsWhy:


As you can see the critical part of the stack is missing; DeveloperView_CrashNullReferenceException_m5366 (and NullCheck).

It would be good to get your opinion on the empty stack traces received when using the C# unhandled exception handler on iOS. Does it even make sense for us to open a bug report on this, seeing as we have no way of reproducing it?

With regards to the native crashes - these would be preferable in the long run if a solution could be found to produce stacktraces that include the source of raising the exception. Normally the full stack should be available when calling abort(), but maybe the exception is caught and rethrown by the engine causing us to loose precious information. Does it make sense to report a bug / feature request for this?

Best regards,
Morten Nielsen

 

Yes we do have that information available and yes they are all 32 bit devices. We will upgrade to the latest 4.6.8 patch release for our next submissions.

With regards to the native crash callstack, then I am almost certain that it does not provide the full callstack. We will create a test project and file a bug report.

Thanks a lot for your speedy replies and the great insight!

Best,
Morten

 

Hi Josh,

Yes we were able to get that working correctly with the latest 4.6.x version of Unity, so that solved it for us.

Best,
Morten

 

Hi Josh,

Are you talking about unhandled exceptions in managed code here?

The manual suggests to use "fast but no exceptions" and never to use try/catch for iOS; but are handled exceptions in managed code meant to work normally with IL2CPP, even with "fast but no exceptions"?

Thanks

 

Thanks, this is very helpful!

Just out of curiosity.. Before IL2CPP, this option affected exceptions in the native code as well, right?