Unity troubleshooting and locating the problem of libunity.so crash (automatic+manual)

A null pointer crash problem often occurs in the online crash statistics log. The keywords are signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000, The call chain points to libunity.so.

problem

Although the call chain pointed to libunity.so when the crash occurred, there was no way to start with what was executed and what method was called. For example, in the following log, you do not know what libunity.00966c68 is:

 E AndroidRuntime:   at libunity.00966c68(Native Method) E AndroidRuntime:   at libunity.00965318(Native Method) E AndroidRuntime:   at libunity.005b7d18(Native Method) E AndroidRuntime:   at libunity.005b7d50(Native Method) E AndroidRuntime:   at libunity.005b7f28(Native Method) E AndroidRuntime:   at libunity.006a43d0(Native Method) E AndroidRuntime:   at libunity.006b2a70(Native Method)

Therefore, we need to find a method to convert the error reported by libunity.so call to a specific method name. This article takes the error report I encountered as an example to briefly record the Debug method.

Note: The new version of Unity is compiled in IL2CPP mode, and engine tailoring is enabled by default. After clipping, the corresponding symbol table is as follows:
IL2CPP does not package libunity.so and other symbol tables (Symbols) correctly

Method 1: Upload so library symbol table (only for unmixed apps, automatic translation)

This method is only applicable to Bugly, a platform that supports symbol table upload, and your program is required to No Android code confusion Of.

The symbol table of Unity libunity.so can be found in the following directory:

Note that the symbol table here corresponds to the complete library that is not checked for engine clipping

 Debug version: Editor\Data\PlaybackEngines\AndroidPlayer\Variations\mono\Development\Symbols Release: Editor\Data\PlaybackEngines\AndroidPlayer\Variations\mono\Release\Symbols

Depending on the platform, you can find different folders, and libunity.sym.so is the symbol table of the so library.

Use the official Bugly tool to transfer the libunity.sym.so symbol table to the online statistics platform, and then the platform will automatically replace the so library error in the crash report with the call chain symbol (that is, the method name).

 java -jar buglyqq-upload-symbol.jar -appid [AppId] -appkey [Appkey] -bundleid com.test.azimiao -version 1.0.0 -platform Android -inputSymbol libunity.sym.so

After successful upload, there should be so symbol table in the background of the bug:

I passed it on and found it was not good. Later, I asked Android students to know that after Unity exported the project to them, they added another layer of code confusion.

I guess the character of the crash log has changed due to code confusion. It should be that the error reported by libunity.so+call stack has changed to libunity.call stack, so it cannot be automatically recognized by platforms such as bugly.

Method 2. Manual translation according to symbol table

Since uploading symbol tables does not work, select manual translation.

Of course, the manual translation here is not to analyze binary manually, but to use existing tools to translate one line at a time.

First, find * - addr2line in your ndk folder. It is a tool that converts the memory address of the call stack to the line number.

  • 32-bit APK so library uses arm linux androideabi addr2line

  • The 64 bit APK so library uses aarch64 linux android addr2line

Use the following command to convert the memory address of the call stack into the corresponding content of the symbol table and output it:

 ./*-addr2line.exe -f -C -e libunity.sym.so 00966c68

If the method is correct, the corresponding method name will be output:

Translate the error report in the above call chain log line by line, and the final error report is as follows:

 VideoClipPlayback::DetectEndReached() VideoPlaybackMgr::Update() ExecutePlayerLoop(NativePlayerLoopSystem*) PlayerLoop() UnityPlayerLoop() nativeRender(_JNIEnv*, _jobject*)

It can be seen that this is a crash caused by using the built-in VideoPlayer.

What is the error in this example

The above example uses a libunity error log. What is the reason for this error? What does a null reference represent?

This is actually a long-standing bug in Unity's built-in VideoPlayer: when the VideoPlayer starts playing and is destroyed immediately, some internal logic will directly use the destroyed object, causing this problem.

Unity claims that this problem was fixed in 2018.4.35f1 and 2020.2. See Unity Issue Tracker # 1241848 for details.

Zimiao haunting blog (azimiao. com) All rights reserved. Please note the link when reprinting: https://www.azimiao.com/8591.html
Welcome to the Zimiao haunting blog exchange group: three hundred and thirteen million seven hundred and thirty-two thousand

Comment

*

*