Search Unity

  1. Full schedule for #UniteBerlin is now available! Featuring talks on our roadmap, hands-on labs and much more! Check it out!
    Dismiss Notice
  2. Unity 2018.1 has arrived! Read about it here
    Dismiss Notice
  3. Scriptable Render Pipeline improvements, Texture Mipmap Streaming, and more! Check out what we have in store for you in the 2018.2 Beta.
    Dismiss Notice
  4. ARCore is out of developer preview! Read about it here.
    Dismiss Notice
  5. Magic Leap’s Lumin SDK Technical Preview for Unity lets you get started creating content for Magic Leap One™. Find more information on our blog!
    Dismiss Notice
  6. 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:
    4
    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,111
    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,111
    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:
    4
    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,111
    I'm not sure. Can you share the symbolicated stack trace?
     
  6. Zachary625

    Zachary625

    Joined:
    Feb 29, 2016
    Posts:
    4
    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,111
    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:
    4
    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.