No exceptions when exceptions enabled, crashing with an exception in release version

Hi - I’ve got my game running just fine in development mode with exceptions enabled set to full. Running this locally in Firefox displays no exceptions. If I then switch ‘enable exceptions’ to None and build the project with the ‘fastest’ option selected opening the game in Firefox gets to the loading screen but then throws a message about an exception happening but not caught. This is the console log:

Successfully compiled asm.js code (loaded from cache in 746ms) TTI%20webGL%20release.js
"run() called, but dependencies remain, so not running" index.html:33:6

"pre-main prep time: 323 ms" index.html:33:6

"Calling stub instead of signal()" index.html:33:6

"Initialize engine version: 5.0.1f1 (5a2e8fe35a68)" index.html:29:8
"Renderer: Mozilla" index.html:29:8
"Vendor:   Mozilla" index.html:29:8
"Version:  WebGL 1.0" index.html:29:8
"GLES:     0" index.html:29:8
"ANGLE_instanced_arrays GL_ANGLE_instanced_arrays EXT_blend_minmax GL_EXT_blend_minmax EXT_color_buffer_half_float GL_EXT_color_buffer_half_float EXT_frag_depth GL_EXT_frag_depth EXT_sRGB GL_EXT_sRGB EXT_texture_filter_anisotropic GL_EXT_texture_filter_anisotropic OES_element_index_uint GL_OES_element_index_uint OES_standard_derivatives GL_OES_standard_derivatives OES_texture_float GL_OES_texture_float OES_texture_float_linear GL_OES_texture_float_linear OES_texture_half_float GL_OES_texture_half_float OES_texture_half_float_linear GL_OES_texture_half_float_linear OES_vertex_array_object GL_OES_vertex_array_object WEBGL_color_buffer_float GL_WEBGL_color_buffer_float WEBGL_compressed_texture_s3tc GL_WEBGL_compressed_texture_s3tc WEBGL_depth_texture GL_WEBGL_depth_texture WEBGL_draw_buffers GL_WEBGL_draw_buffers WEBGL_lose_context GL_WEBGL_lose_context MOZ_WEBGL_lose_context GL_MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc GL_MOZ_WEBGL_compressed_texture_s3tc MOZ_WEBGL_depth_texture GL_MOZ_WEBGL_dept" index.html:29:8
"h_texture" index.html:29:8
"Creating OpenGLES2.0 graphics device" index.html:29:8
"Loader started

" TTI%20webGL%20release.js:1:228213
"Unloading 2 Unused Serialized files (Serialized files now loaded: 0)" index.html:29:8
"UnloadTime: 0.538821 ms" index.html:29:8
"Invoking error handler due to
uncaught exception: 42825080 - Exception catching is disabled, this exception cannot be caught. Compile with -s DISABLE_EXCEPTION_CATCHING=0 or DISABLE_EXCEPTION_CATCHING=2 to catch."

What, if anything, can I do to debug this? Thanks!

you have to run it with exception handling on, but then go into the logs, find the exception, and FIX IT. that is the only way your game will run without exception handling turned on.

1 Like

In your dev build (with exceptions) there’s probably some exception that occurs (but is being caught? or otherwise i’m not sure why it’s not crashing in the development build).

In release builds, instead of throwing it the game simply crashes.

You should probably look into the places where you code may throw exceptions (although this can be a bit difficult in case it’s a large project).

Thanks for the reply but I think you might need to re-read the title/post. With exception handling on there are no exceptions.

Hi, thanks for the reply, the project is a decent size … Are you saying that any try/catch handling will be stripped if the exception handling toggle is off??

The toggle is not for exception handling, is for enabling exceptions as a feature…

Without it, there’s no concept of exceptions (any exception that was thrown in your original code will cause an immediate crash of the game).

Wow, that’s insane, how are we supposed to handle exceptions then? Could you point me to where this is explained in the documentation? Thanks!

Edit- lazy me looked this up:http://docs.unity3d.com/Manual/webgl-building.html I’m assuming the issue is in one of the exception handlers I’ve written, will remove those and then test with exceptions on again. Thanks for your help.

i did read it, and read your post and had the exact same issue you described.

The fact is, you have an exception, says so right in the error. When you use a development build and have exception handling turned on, your game fails silently because emscripten adds a bunch of try/catches for various different code paths and that includes NullReferenceExceptions which are most common. When you turn off exception handling, those try/catches aren’t compiled into your code and thus your game crashes and doesn’t know why.

The root of the problem is that you have an exception somewhere, it could be an asynchronous call or coroutine you have somewhere that since a release build without exception handling runs faster, changes the execution time of your code and thus changes state and could cause issues.

If you really aren’t getting any information at all about any warnings in the javascript console when you DO have exception handling on (even though they are handled, it should still print them out) then you have a few options and none of them are very nice. But will help you narrow down where your exception is.

-Start disabling game objects in your scene and doing a build without exception handling until you don’t get any exceptions anymore. Once that works, you should know what objects are causing problems and you can fix the exception in your code.
-Add defensive log statements to all your code, if you’re references are always checked for null before being accessed, then you will know about a NullReference exception before it happens and can change your code to prevent it.
-Check any plugins/dlls in your project and make sure if you have any iOS/Android ones, that they are set to build only to platform they are specifically needed in and not WebGL if they aren’t needed, they might have Code that fails safely when exception handlign is turned on but fails when its off.

Most of all, Good Luck, this implementation of WebGL is not easy to debug by any sense and can be quite tedious.

Hey, thanks for taking the time to type this up, much appreciated. Extremely frustrating that it looks like the only route left is to start making build after build until the black box starts working!

The idea is to be defensive with your programming.

example:
This will throw an exception if there is no AudioSource on the object.

GetComponent<AudioSource>().enabled = false;

This will not throw an exception if there is no AudioSource on the object.

AudioSource audioSource = GetComponent<AudioSource>();
if(audioSource == null)
{
    Debug.LogWarning("My object has no AudioSource Component and i'm trying to access it!");
}
else
{
    audioSource.enabled = false;
}

I’m not saying this is your problem, but the most common source of Exceptions in most people’s projects, is they got lazy and assumed that the state of their object has been initialized properly, and thus they can assume that a long chain of property references is still good.

i.e. gameObject.GetComponent().velocity = GetComponent().rectTransform.anchoredPosition.x;

in the above example, if gameObject, its RigidBody component, the Transform Component, the rectTransform, or the anchoredPosition of the rectTransform are null? then you will get an exception.

Getting a reference to something won’t cause an exception, but using a reference that is null to look up a property of it will.

Hope this example sheds some light, even though it is rather straight forward.

Glad i could be of help :slight_smile:

Thanks for the example, where possible I believe I’ve already done this but no doubt useful for posterity. My best guess for what might still be causing me issues is in the load game code which has multiple try/catch boo is around things like base64 deciding and file IO, guess I’ll just comment out all the exception handling I can find and see what’s then breaking. Cheers!

This is complex, but one way to debug these exceptions is to put a breakpoint on the _il2cpp_raise_exception function in your generated Javascript. This then lets you see a call stack when the exception originated, which is unfortunately not preserved when the uncaught exception is later reported. You can also browse up the callstack and inspect things in the debugger, at the asm.js level. It is heavy-going but sometimes you can get the information you need.

Yes, what gfoot said works for logging the exception stack trace (as when you turn exceptions on, chances are, it will just get caught). I do the same, though I tend to use cxa_throw. I realize that this is tedious, so I will make sure that Unity will automatically log stack traces when exceptions are disabled for 5.1.

Sounds like a good improvement, thanks!