Search Unity

  1. Improved Prefab workflow (includes Nested Prefabs!), 2D isometric Tilemap and more! Get the 2018.3 Beta now.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Let us know a bit about your interests, and if you'd like to become more directly involved. Take our survey!
    Dismiss Notice
  4. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice
  5. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

SIGABRT crash soon after app launch

Discussion in 'Android' started by Zachary625, May 16, 2018.

  1. Zachary625

    Zachary625

    Joined:
    Feb 29, 2016
    Posts:
    6
    Hey guys!
    This being my first post on unity forum, excited and nervous for the lack of format or anything else necessary! I've encountered a crash which leaves me no way to reproduce and no clue to research, and I thought fellow unity developers could provide some information or suggestions. Thanks in advance!

    Our product is an old school android game developed with Unity 5.6.3f1, using IL2CPP for release builds with minSDKVersion 15 and targetSDKVersion 26, and I'm encountering a SIGABRT on android devices. The running time is mostly among 10s to 1min, but small parts of this crash happens at 15mins or even later.

    The stack traces are showing that the crash is located in a thread called FinalizerDaemon, like below:

    #00 pc 0004a1c0 /system/lib/libc.so (tgkill+12) [armeabi-v7a]
    #01 pc 00047953 /system/lib/libc.so (pthread_kill+34) [armeabi-v7a]
    #02 pc 0001d955 /system/lib/libc.so (raise+10) [armeabi-v7a]
    #03 pc 000194a1 /system/lib/libc.so (__libc_android_abort+34) [armeabi-v7a]
    #04 pc 000170e8 /system/lib/libc.so (abort+4) [armeabi-v7a]
    #05 pc 01ad3ed8 /data/app/{BUNDLE_ID}-1/lib/arm/libil2cpp.so (__gnu_cxx::__verbose_terminate_handler()+348) [armeabi-v7a]
    #06 pc 01aaa01c /data/app/{BUNDLE_ID}-1/lib/arm/libil2cpp.so (__cxxabiv1::__terminate(void (*)())+8) [armeabi-v7a]
    #07 pc 01aaa0bc /data/app/{BUNDLE_ID}-1/lib/arm/libil2cpp.so (std::terminate()+12) [armeabi-v7a]
    #08 pc 01aaa248 /data/app/{BUNDLE_ID}-1/lib/arm/libil2cpp.so (__cxa_throw+156) [armeabi-v7a]
    #09 pc 01a6d578 /data/app/{BUNDLE_ID}-1/lib/arm/libil2cpp.so [armeabi-v7a]
    #10 pc 01a6d3dc /data/app/{BUNDLE_ID}-1/lib/arm/libil2cpp.so [armeabi-v7a]
    #11 pc 01a6d2bc /data/app/{BUNDLE_ID}-1/lib/arm/libil2cpp.so [armeabi-v7a]
    #12 pc 004e3980 libunity.so ScopedThreadAttach::ScopedThreadAttach(ScriptingDomainPtr) [armeabi-v7a]
    #13 pc 00a492cc libunity.so UnityJavaProxy_finalize(_JNIEnv*, _jobject*, int) [armeabi-v7a]
    #14 pc 008ee899 /data/app/{BUNDLE_ID}-1/oat/arm/base.odex (oatexec+813209) [armeabi]
    java:
    com.unity3d.player.ReflectionHelper.a(Unknown Source)
    com.unity3d.player.ReflectionHelper$1.finalize(Unknown Source)
    java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:222)
    java.lang.Daemons$FinalizerDaemon.run(Daemons.java:209)
    java.lang.Thread.run(Thread.java:762)



    The most curious clue is that, in most reports, the recent logcat records contain the following warnings almost always right before the crash:

    05-16 08:49:20.529 25549 25549 W Unity : Timeout while trying to pause the Unity Engine.
    05-16 08:49:20.641 25549 25549 W Unity : Not running Google VR from an Activity; Ignoring execution request...


    Also, logcat shows that before these warnings the app was switched into background. Since we do have android AlertDialog regarding permission rationales and permission request dialogs by android system on android 6.0 and above, I strongly suspect that during the process of prompting the user for permissions, the app was switched to background somehow, and this might coincide with some unity behaviors that caused the engine failed to pause?

    Any suggestions or help would be welcome!
     
  2. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,374
    Thanks for reporting this issue, and welcome to the forums!

    Unfortunately, there is not too much we can do without a reproducible test case. I don't recall seeing a crash like this before. I would like to know which functions are in the call stack for the libil2cpp.so frames that have missing information. I'll check with our Android team about options for symbolicating stack traces.

    Do you see this crash on a regular basis? If so, does it seem to be tied to a certain type of device?
     
  3. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,374
    I've learned that you can symbolicate the libil2cpp.so frames using the ndk-stack utility: https://developer.android.com/ndk/guides/ndk-stack

    The debug symbols are in a .zip file next to the generated .apk. You should be able to extract that file, then use ndk-stack to determine the missing frames in that call stack.
     
  4. Zachary625

    Zachary625

    Joined:
    Feb 29, 2016
    Posts:
    6
    Seems regular enough, and the device or API level distribution don't seem peculiar. But many thanks on the method to symbolicate the frames! Gives us new directions.

    This SIGABRT have been emerging a lot since our last app update(which contains modifications on targetSdkVersion and other SDKs), but due to the lack of reproduction of the issue, it's hard to do tests by ruling out some of the modifications.
    And we're not sure the app would appears to be crashed, we guess it might happen when user press home button or sth, and instead of pausing, the app crashed. Is this possible if there were some faulty settings, incompatible libraries or misbehaving plugins?
     
  5. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,374
    I'm not sure. Can you share the symbolicated stack trace?
     
  6. Zachary625

    Zachary625

    Joined:
    Feb 29, 2016
    Posts:
    6
    Hi!
    I haven't been able to find the .zip file you mentioned, but I do have found the libil2cpp.sym, and used addr2line to symbolicate, wonder if these makes sense?

    Code (JavaScript):
    1. > arm-linux-androideabi-addr2line.exe -f -C -e libil2cpp.sym 01a6d578 01a6d3dc 01a6d2bc
    2.  
    3. > il2cpp::icalls::mscorlib::System::Array::Clone(Il2CppArray*)
    4. C:\android-ndk-r10e\sources\cxx-stl\gnu-libstdc++\4.9\include\ext/new_allocator.h:116
    5.  
    6. il2cpp::icalls::mscorlib::System::Array::ClearInternal(Il2CppArray*, int, int)
    7. d:\Unity563\Editor\Data\il2cpp\libil2cpp\icalls\mscorlib\System/Array.cpp:25
    8.  
    9. il2cpp::icalls::mscorlib::System::Runtime::InteropServices::Marshal::PtrToStructure(Il2CppIntPtr, Il2CppReflectionType*)
    10. d:\Unity563\Editor\Data\il2cpp\libil2cpp\icalls\mscorlib\System.Runtime.InteropServices/Marshal.cpp:230
     
  7. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,374
    I think that libil2cpp.sym is the correct file, but I don't believe this could be the call stack, unfortunately. Is it possible that this libil2cpp.sym is from a different build of the project?
     
  8. Zachary625

    Zachary625

    Joined:
    Feb 29, 2016
    Posts:
    6
    Pretty sure since this was found from our version vault right beside the apk we published, I'll be looking at other reports and see if this is a noise...
     
    JoshPeterson likes this.
  9. BoboShu

    BoboShu

    Joined:
    Nov 20, 2014
    Posts:
    36
    i have same problem 5.6.6f2
    here is my stack

    @Zachary625
    @JoshPeterson

    Code (CSharp):
    1.  
    2. # FinalizerDaemon(17942)
    3.  
    4. SIGABRT
    5.  
    6. 解析原始
    7. 1 #00 pc 0004b3ac /system/lib/libc.so (tgkill+12) [armeabi-v7a]
    8. 2 #01 pc 0001a473 /system/lib/libc.so (abort+54) [armeabi-v7a]
    9. 3 #02 pc 02319dac libil2cpp.so __verbose_terminate_handler (/s/ndk-toolchain/src/gcc/gcc-4.9/libstdc++-v3/libsupc++/vterminate.cc:95) [armeabi-v7a]
    10. 4 #03 pc 022efef0 libil2cpp.so __terminate (/s/ndk-toolchain/src/gcc/gcc-4.9/libstdc++-v3/libsupc++/eh_terminate.cc:47) [armeabi-v7a]
    11. 5 #04 pc 022eff90 libil2cpp.so terminate (/s/ndk-toolchain/src/gcc/gcc-4.9/libstdc++-v3/libsupc++/eh_terminate.cc:57) [armeabi-v7a]
    12. 6 #05 pc 022f011c libil2cpp.so __cxa_throw (/s/ndk-toolchain/src/gcc/gcc-4.9/libstdc++-v3/libsupc++/eh_throw.cc:87) [armeabi-v7a]
    13. 7 #06 pc 003a3ff8 libil2cpp.so il2cpp::vm::Thread::Register(Il2CppThread*) (D:\Unity5.6.6f2\Editor\Data\il2cpp\libil2cpp\vm/Thread.cpp:412 [Inline: il2cpp::vm::TerminateBackgroundThread(void*)]) [armeabi-v7a]
    14. 8 #07 pc 003a3e5c libil2cpp.so il2cpp::vm::Thread::Initialize(Il2CppThread*, Il2CppDomain*) (D:\Unity5.6.6f2\Editor\Data\il2cpp\libil2cpp\vm/Thread.cpp:130) [armeabi-v7a]
    15. 9 #08 pc 003a3d3c libil2cpp.so il2cpp::vm::Thread::Attach(Il2CppDomain*) (D:\Unity5.6.6f2\Editor\Data\il2cpp\libil2cpp\vm/Thread.cpp:110) [armeabi-v7a]
    16. 10 #09 pc 004e6834 libunity.so ScopedThreadAttach::ScopedThreadAttach(ScriptingDomainPtr) [armeabi-v7a]
    17. 11 #10 pc 00a4f59c libunity.so UnityJavaProxy_finalize(_JNIEnv*, _jobject*, int) [armeabi-v7a]
    18. 12 #11 pc 0006fdf3 /data/app/com.Alioth.JusticeSchool.cn-dXuGfpIOAqAkd-jjmyr73g==/oat/arm/base.odex (oatexec+273907) [armeabi]
    19. 13 java:
    20. 14 com.unity3d.player.ReflectionHelper.nativeProxyFinalize(Native Method)
    21. 15 com.unity3d.player.ReflectionHelper.a(Unknown Source:0)
    22. 16 com.unity3d.player.ReflectionHelper$1.finalize(Unknown Source:2)
    23. 17 java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:253)
    24. 18 java.lang.Daemons$FinalizerDaemon.runInternal(Daemons.java:240)
    25. 19 java.lang.Daemons$Daemon.run(Daemons.java:103)
    26. 20 java.lang.Thread.run(Thread.java:784)
     
  10. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,374
    @BoboShu

    Thanks for the symbolicated stack trace. This looks like a rather interesting issue. Do you have symbolicated stack traces for the other threads in the process?

    This problem occurs while IL2CPP is shutting down. It is waiting for all background threads in managed code to exit, and it looks like a new thread is being started during the shut down process. IL2CPP should be able to handle this case, but having more information about what else is happening could help us understand the situation.