I’ve got minidumps uploading on Windows Native from Unity 3D, which uses a modified version of mono. However, I get dumps like this:
* UnityPlayer +0x127f6fe `Utils_CUSTOM_ForceCrash` corebindings.gen.cpp:54742
* <unknown> 0x01b25d869e3a `<unknown>`
* <unknown> 0x01b25d869d8b `<unknown>`
* <unknown> 0x01b17a6d792e `<unknown>`
* mono-2.0-bdwgc +0x012cbaf `mono_jit_runtime_invoke` mini-runtime.c:2809
* mono-2.0-bdwgc +0x00b2121 `do_runtime_invoke` object.c:2919
* mono-2.0-bdwgc +0x00bb2f1 `mono_runtime_invoke_checked` object.c:3072
* mono-2.0-bdwgc +0x00bba88 `mono_runtime_try_invoke_array` object.c:5264
* mono-2.0-bdwgc +0x00bb285 `mono_runtime_invoke_array_checked` object.c:5141
* mono-2.0-bdwgc +0x00602b3 `ves_icall_InternalInvoke` icall.c:3357
* <unknown> 0x01b245793b80 `<unknown>`
The top three stack frames are likely undecoded C#. Do you have a way to decode crash dumps coming from mono I could try to get working?
Failing that, is there a way to keep a raw crash dump in sentry without decoding it?
Short answer is that you can’t get a minidump symbolicated to C# because C# compiles to IL and what you’ll get in the minidumps is JIT’ed code. Unless it was IL2CPP which means you could likely get this symbolicated to the C++ code generated from the .NET IL.
Are you using IL2CPP or is this really Mono with JIT? and there’s a native crash there that brings the process down.
Unity either uses il2cpp or mono AOT (ahead of time, but otherwise like JIT). I know il2cpp will work, but I’m not sure what we’ll ship with, so I was wondering if there’s any way to support the AOT route.
I don’t believe Unity supports Mono AOT anymore. If you’re using Mono, it’s with JIT.
It’s also what I read from their docs.
So if you’re targeting Mono, it’ll be JIT’ed.
Our Unity lite SDK captures the C# stack traces but with a minidump we are not able to symbolicate that back to the original C# code.
Ah, I guess you’re right about the JIT.
Yeah, the error logging is great. In your full C# library is there anything that can handle application crashes?
If the crash was caused by a .NET exception (say C# code), the SDK will capture it and make sure its submitted before the app crashes. If you called a native plugin and that crashes, that’ll crash and not call the Unity SDK.
In this case, we could be exploring alternatives here. Like the minidump for example, to symbolicate to the native code if that was written in C++ or something else. Sentry has great support to minidumps already.
What are your targets? Android, iOS, Windows, or else?
Just windows native. I do have it working, with an edited version of the Unity lite SDK and crashpad.
The very common pattern in Unity3d that concerns me is C++ calls into C#, which calls into C++, which crashes. It’s currently decoding the C++ very well, but the C# part of the callstack is invaluable.
Oh, I see that there’s an option to store crash dumps referred to in the docs. Is that information old, or does it show up for paid plans?
https://docs.sentry.io/enriching-error-data/attachments/#enabling-crash-report-storage
It should be available to everyone. The new billing was released so you should be able to get a plan with a number of GB for attachments (i.e minidump).
Maybe reach out in this case: https://sentry.io/support/ if you’re a paying customer, they’ll be able to help you better than me