How to understand crash reports in Unity Analytics

Unity Services
,
1

Hello,

I have so many of these similar crash reports in Unity analytics dashboard, but can not understand where the crash is happening. Can anyone please help with what this Native StackTrace means? I am using Unity 2019.1.4f1 and Android build with IL2CPP and also uploaded the symbol file to the analytics dashboard. But there are some symbol missing in the stack trace. I can not understand how to find where the crash is happening. The Logs tab in the report also does not contain any error. Please help.

The report title is:
Native Crash - CrashReporting::Android::SignalHandler(int, siginfo*, void*) (Unknown File)

Native StackTrace:

Thread 0 (crashed)
0 libunity.so 0x00000000a343ca84 CrashReporting::Android::SignalHandler(int, siginfo*, void*)
1 libunity.so 0x00000000a2f39a8c NativeRuntimeException::signal_handler(int, siginfo*, void*)
2 libart.so 0x00000000b4707936
3 libc.so 0x00000000b6c5a87c
4 libc.so 0x00000000b6c755aa
5 libunity.so 0x00000000a30de71c BaseAllocator::TryDeallocate(void*)
6 libunity.so 0x00000000a30e0e00 MemoryManager:: Deallocate(void*, MemLabelId)
7 libunity.so 0x00000000a2d696b8 dynamic_array<unsigned char, 0u>::~dynamic_array()
8 libunity.so 0x00000000a3081508 Texture2D:: DestroyTexture()
9 libunity.so 0x00000000a30ad528 Cubemap::~Cubemap()
10 libunity.so 0x00000000a30d6220 delete_object_internal(Object*)
11 libunity.so 0x00000000a3030f28 CleanupAllObjects()
12 libunity.so 0x00000000a30311bc CleanupEngine()
13 libunity.so 0x00000000a30258b4 PlayerCleanup(bool)
14 libunity.so 0x00000000a2f37e24 UnityDeinitApplication()
15 libunity.so 0x00000000a2f31128 nativeDone(_JNIEnv*, _jobject*)

2

We have so many crashes with the following stack trace, in line 4, 5, 6, 7 it is something related to physx but the line 0 it is about crash reporting, so I can not understand whether the crash is caused by physx or the crash reporting system itself. And as it is written that “thread 0 (crashed)”, does this mean the line 0 which is related to crash reporting has crashed? Are those numbers from 0 to 17 represent thread numbers? Somebody please help me.

3

Is there anybody who can help me?

4

Hi @Sailendu , sorry for the delay. Most of Unity is away in Denmark for Hack Week so getting replies has been slow going. The last lines in your stack trace are normal for native crashes since our code is the last to catch a crash and generate a stack trace from it.

Looking more closely at them, they seem to be crashes inside of Unity’s code in Texture2D and PhysX, however I’m not familiar enough with those areas to know what might be causing them. I’d recommend asking in the Graphics and Physics forums, respectively, about those specific stack traces and make sure they’re aware of them.

5

@Ryan-Unity Thanks a lot for the response, I will post in those forums as well. Can you please tell me how the stack trace order is written? As there are line number from 0 to 17, are these “top to bottom” or “bottom to top” in execution order? And as line 0 is related to CrashReporting, is the crash caused by CrashReporting system itself? Sorry for asking so many questions, I have no knowledge about stack traces. This is causing so many crashes in my app and is affecting the rating and ranking. Please help.

6

No worries, you’re perfectly fine for asking questions. When you look at a stack trace, the top-most line is the last line of code to be executed while the code at the bottom of the stack is the first to be called in the main execution loop.

7

Thank you so much for explaining, this knowledge is very valuable for me.
Then, does that mean the crash happened because of the crash reporting system?
Because it says “Thread 0 (crashed)” in the beginning.

8

The “Thread 0 (crashed)” is referring to the specific thread that these lines of code were operating in. With multi-core processors, multiple lines of execution can be run at the same time but on different threads. Your stack traces show that the crashes happened in Thread 0, or the main thread. However, just because the Crash Reporter was the last line of code in the stack trace doesn’t mean that it was the reason for the crash.

When a native crash happens, the Crash Reporter catches it before the thread starts to unwind and fall back to the top of the stack so that it can record the full stack trace. It then saves the report in a place where it can be sent later since the app is in the process of being shut down by the OS when that kind of crash happens. The last thing the OS wants a crashing app to do is execute more code that could be potentially harmful. But once your app is restarted then the Crash Reporter sends out the saved report to our servers where you can access it from the Dashboard.

I hope that helps to clear things up a little.

1 Like
9

That’s an amazing information, thanks a lot again. Now I have a better understanding of how it works. I will now post in those 2 specific forums you mentioned above.

1 Like
10

@Sailendu did you get any solution for the native crash…

11

Nope! lastly I found most crashes were because of a bug in the physx engine, which is in my 2nd post in this thread. But I could not do anything about it, and because I made so many changes to my project, so I tried to roll back to older Unity version, but it took me more than a month because I made so many changes to the project using Unity 2019. Then because of this, my crash rate increased, my app lost ranking, everyday downloads decreased by 90%. My point is I could not find a solution, I asked in many forums, stackoverflow, but sound nothing. So I gave up. If you find any solution, please let me know. It would be very helpful for me.

One more thing is, I read somewhere that Unity upgraded the physx sdk in version 2020, which is currently in alpha so I haven’t tried it. I hope this issue will be gone in 2020.