Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Bug 2022.2.19f1 / 2023.1.0b17 native crashe when finalizing AnimationCurve

Discussion in 'Android' started by arturaz, May 23, 2023.

  1. arturaz

    arturaz

    Joined:
    Mar 28, 2013
    Posts:
    30
    Hi!

    We've encountered a problem while migrating our project from `2020.3.40f1` to `2022.2.19f1`, it seems there's a problem with `AnimationCurve` being attempted to be destroyed without it ever getting constructed in the first place, which evidently results in a crash. Also worth mentioning is that the problem manifests itself on `Android` platform only and no matter what configuration or settings those are assembled with, OS versions don't affect the behavior as well.

    The crash happens when we load a scene, exit that scene and then run garbage collection.

    Something along these lines: `main menu` -> `level` -> `main menu` -> `run gc`.

    The first thing we concentrated on is the removal of all of our explicit `AnimationCurve` uses case from the codebase just to be able to isolate the possibility of us doing something wonky with it, but it didn't prove to be the case here.

    Next, we decided to try other `Unity 2022` releases just to exclude the possibility of a regression that could've been introduced at some point. We've even given a go to the `2023.1 beta` release. No dice.

    We have also tried disabling incremental GC, building in development mode, switching `IL2CPP` flags to produce a smaller build instead of a more optimized one, and using `GLES` renderer instead of a `Vulkan`-based one. Still no positive outcome.

    The last resort for us was to export the Android project locally and dig into IL2CPP-generated code to see what was going under the hood. We added a lot of logging around the `AnimationCurve` functions to see if anything gets corrupted for some reason.

    Our log output would look like this for proper `AnimationCurve` construction and destruction flows (
    i.e. `AnimationCurve_Finalize` invocations that clearly have a matching construction call `AnimationCurve__ctor` before it):


    AnimationCurve__ctor_mEABC98C03805713354D61E50D9340766BD5B717E:  0=482526307184 1=482526307184 2=482526307184 this=483584882176
    AnimationCurve_Finalize_m803AC16166EE497C4DFA996B15692D91F4D04C3C: 0=482526307184 1=482526307184 2=482526307184 this=483584882176
    memzero AnimationCurve_Finalize_m803AC16166EE497C4DFA996B15692D91F4D04C3C: 0=0 1=0 2=0 this=483584882176


    In case there's a mismatch, i.e. the finalization is performed on an `AnimationCurve`, which hasn't been constructed yet, we'd see this (preceded with a `=====>` just to make it easier to spot and filter out):

    =====> AnimationCurve_Finalize_m803AC16166EE497C4DFA996B15692D91F4D04C3C: 0=12970367422304525504 1=0 2=0 this=484505394416


    Every log message provides the following information:

    - 3 copies of the pointer stored within `AnimationCurve_tCBFFAAD05CEBB35EF8D8631BD99914BE1A6BB354` the (`0=…, 1=…, 2=…`) parts.
    - pointer to the `AnimationCurve_tCBFFAAD05CEBB35EF8D8631BD99914BE1A6BB354` instance itself (the `this=` part)

    `AnimationCurve_tCBFFAAD05CEBB35EF8D8631BD99914BE1A6BB354` would look like this now:

    struct AnimationCurve_tCBFFAAD05CEBB35EF8D8631BD99914BE1A6BB354  : public RuntimeObject
    {
    intptr_t ___m_Ptr;
    intptr_t ___m_Ptr2;
    intptr_t ___m_Ptr3;
    };


    Copies were introduced to see if there's some sort of memory corruption taking place, which somehow either reuses some older instances without ever re-constructing them properly or it's simply a case of double-freeing. They are assigned along the "primary" `__m_Ptr` at the same places in the code (like `AnimationCurve__ctor_mEABC98C03805713354D61E50D9340766BD5B717E`, etc).

    Also, we extended the `AnimationCurve_Finalize` function to include a logic, which would check whether all of the pointer copies are identical and if there are not, then it would log the case and skip destruction of the `AnimationCurve` instance altogether:

    Code (CSharp):
    1.  
    2. IL2CPP_EXTERN_C IL2CPP_METHOD_ATTR void AnimationCurve_Finalize_m803AC16166EE497C4DFA996B15692D91F4D04C3C (AnimationCurve_tCBFFAAD05CEBB35EF8D8631BD99914BE1A6BB354* __this, const RuntimeMethod* method)
    3. {
    4.   {
    5.   }
    6.   {
    7.     auto __finallyBlock = il2cpp::utils::Finally([&]
    8.     {
    9.  
    10. FINALLY_0010:
    11.       {
    12.         Object_Finalize_mC98C96301CCABFE00F1A7EF8E15DF507CACD42B2(__this, NULL);
    13.         return;
    14.       }
    15.     });
    16.     try
    17.     {
    18.       intptr_t L_0 = __this->___m_Ptr;
    19.       if (L_0 == __this->___m_Ptr2 && L_0 == __this->___m_Ptr3)
    20.       {
    21.         AnimationCurve_Internal_Destroy_m240B298D0A13EEC1652955C4BDCDBE9B7B2EE296(L_0, NULL);
    22.  
    23.         // zero-out the struct to be sure there are no leftovers in case something reuses the object.
    24.         memset(__this, 0, sizeof(AnimationCurve_tCBFFAAD05CEBB35EF8D8631BD99914BE1A6BB354));
    25.  
    26.         // log normally
    27.       }
    28.       else
    29.       {
    30.         // log the offending case
    31.       }
    32.       goto IL_0018;
    33.     }
    34.     catch(Il2CppExceptionWrapper& e)
    35.     {
    36.       __finallyBlock.StoreException(e.ex);
    37.     }
    38.   }
    39.  
    40. IL_0018:
    41.   {
    42.     return;
    43.   }
    44. }
    Modifying the code this way solved our crashes, but of course, there's no guarantee there won't be any memory leaks associated with it or something even worse (latent segfaults that are waiting to happen, etc).

    Currently, we're sticking to the hack mentioned above, but hoping for a better solution, which wouldn't force us to inject anything into C++ code right before compiling & linking it.

    Segfault's call stack, which might be useful:

    Code (CSharp):
    1. Thread 0 Crashed:
    2. 0   libunity.so                     0x79b143c650        MemoryManager::VirtualAllocator::GetBlockInfoFromPointer
    3. 1   libunity.so                     0x79b14398b8        DualThreadAllocator<T>::Contains
    4. 2   libunity.so                     0x79b14396a8        DualThreadAllocator<T>::TryDeallocate
    5. 3   libunity.so                     0x79b143bc3c        MemoryManager::Deallocate
    6. 4   libil2cpp.so                    0x799dfe01f8        [inlined] AnimationCurve_Internal_Destroy_m240B298D0A13EEC1652955C4BDCDBE9B7B2EE296 (UnityEngine.CoreModule.cpp:9709)
    7. 5   libil2cpp.so                    0x799dfe01f8        AnimationCurve_Finalize_m803AC16166EE497C4DFA996B15692D91F4D04C3C (UnityEngine.CoreModule.cpp:9749)
    8. 6   libil2cpp.so                    0x799ba95f04        il2cpp::vm::Runtime::InvokeWithThrow (Runtime.cpp:604)
    9. 7   libil2cpp.so                    0x799ba95e50        il2cpp::vm::Runtime::Invoke (Runtime.cpp:590)
    10. 8   libil2cpp.so                    0x799ba8d7c8        il2cpp::gc::GarbageCollector::RunFinalizer (GarbageCollector.cpp:178)
    11. 9   libil2cpp.so                    0x799babee10        GC_invoke_finalizers (finalize.c:1314)
    12. 10  libil2cpp.so                    0x799ba8d710        il2cpp::gc::FinalizerThread (GarbageCollector.cpp:102)
    13. 11  libil2cpp.so                    0x799ba935b0        il2cpp::os::Thread::RunWrapper (Thread.cpp:200)
    14. 12  libil2cpp.so                    0x799bab4958        il2cpp::os::ThreadImpl::ThreadStartWrapper (ThreadImpl.cpp:123)
    15. 13  libc.so                         0x7cf0e52268        __pthread_start
    16. 14  libc.so                         0x7cf0de4a2c        __start_thread
    A bug has been reported: case number IN-41806
     
    Last edited: May 24, 2023
    AliBuck likes this.
  2. Tomas1856

    Tomas1856

    Unity Technologies

    Joined:
    Sep 21, 2012
    Posts:
    3,831
    It's possible there's a bug in managed layer of AnimatioCurve, from which this cpp code is generated.

    You can try asking https://forum.unity.com/forums/animation.52/, since AnimationCurve is handled by Animation team.

    But if you can reproduce this locally, we would love to get a bug report with repro project attached.

    Thank you!
     
  3. kayy

    kayy

    Joined:
    Jul 26, 2011
    Posts:
    110
    We ran into a very similar problem when upgrading from 2022.2.11 to 2022.2.20, the stack trace is almost identical.

    In our case 2022.2.13 turned out to be the last one working. Starting with .14 our app crashes, .21 which was just released did not fix it. The release notes for 2022.2.14 reveal a couple of optimizations related to animations.

    The problem seems to be restricted to IL2CPP builds. A test with Mono as scripting backend on 2022.2.20 worked as expected
     
    arturaz likes this.
  4. arturaz

    arturaz

    Joined:
    Mar 28, 2013
    Posts:
    30
    I very much doubt so. Note that broken finalizer invocations do not have correspondent initialize invocations. If it was in the managed code, you'd see both sides.

    I'd place my bets on some sort of GC bug.
     
  5. GreatVV

    GreatVV

    Joined:
    Feb 6, 2014
    Posts:
    5
    I have this bug as well. It is funny that I tried all steps mentioned in first message and it was also unsuccessful. But I have this bug only on one device out of 6 I tested it.
    I hope it would be fixed soon
     
  6. kayy

    kayy

    Joined:
    Jul 26, 2011
    Posts:
    110
    Interesting, we tested on 2 devices, Galaxy Z Flip4 and Galaxy A12. The crash was reproducible on both of them
     
  7. newstr1

    newstr1

    Joined:
    Sep 22, 2017
    Posts:
    4
    I got the same issue when migrating from 2020 LTS to 2022 LTS.
    There are a lot of AnimationCurve in the project and it was not possible to find a specific case and highlight it in the test project.
    Tell me, please, was someone able to send a bug report with playback on this problem or was it never reported to the developers? I didn't find anything similar in issuetracker.
     
    AliBuck likes this.
  8. kayy

    kayy

    Joined:
    Jul 26, 2011
    Posts:
    110
    I too was unable to file a bug report with a small test project. It happens reproducibly with the huge customer's main project
     
  9. Wriggler

    Wriggler

    Joined:
    Jun 7, 2013
    Posts:
    131
    Yep, I've got the same issue on 2022.3.2f1. Makes our Android version unshippable. I couldn't find any further details on this one outside of this thread. Has anybody had any further luck tracking this one down?

    We recently upgraded our project from 2021 LTS to 2022 LTS, and that seems to be a common issue of people reporting in this thread. Perhaps there's something unexpected happening in the upgrade process...? *shrugs* I'm only seeing this in one particular portion of our game, so perhaps it's an asset issue rather than a general code thing...

    Ben
     
    AliBuck likes this.
  10. newstr1

    newstr1

    Joined:
    Sep 22, 2017
    Posts:
    4
    If you can isolate this particular portion into a separate project and reproduce the bug there - please send a bug report with it, it will help us all in this thread a lot.

    Or at least tell more about your particular portion so that you can try to reproduce this bug for others to bug report.
    The more information - the more chances we have to reproduce and pass the problem to Unity
     
    AliBuck likes this.
  11. Wriggler

    Wriggler

    Joined:
    Jun 7, 2013
    Posts:
    131
    I've got it narrowed down to a ParticleSystem. More specifically, a series of nested ParticleSystems. Calling Play() on that seems to cause the crash. It seems like it's when the GC tries to collect the ParticleSystems that it falls over. This is Android-specific - other platforms are fine.

    I'm still investigating, but thought I'd post my initial findings in case that sounds familiar to anyone else...?

    Ben
     
    AliBuck and newstr1 like this.
  12. rejwan1

    rejwan1

    Joined:
    Jul 3, 2012
    Posts:
    40
    Hey Ben,

    I can confirm we are experiencing the exact issue (Unity 2022.3.3f1), only occurs on IL2CPP, doesn't replicate on mono.
    If particle system is allowed to run enough time, it seems to not reproduce.
    Also seems that it's not related to nested or not, since I flattened the hierarchy of our PS under 1 gameobject (non PS) and it still reproduced.

    I'll update once I find a workaround, this definitely looks like a bug in Unity 2022.
     
    AliBuck likes this.
  13. rejwan1

    rejwan1

    Joined:
    Jul 3, 2012
    Posts:
    40
    @Wriggler

    I have found the root cause for our issue, unsure if it's the same for you.
    We are using UI extensions, particularly UIParticleSystem.

    The root cause was accessing the curve in OnPopulateMesh after it was disabled, caching the frameOverTime struct locally, and accessing it (rather than the actual PS one) - which solved the issue.

    I hope this helps.

    But this is definitely an issue with Unity, that for some reason accessing that struct in that function (lifecycle), causes a GC crash.
     
    AliBuck likes this.
  14. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,896
    Can you submit a bug report for this issue? This is definitely something that we want to address.

    https://unity.com/releases/editor/qa/bug-reporting
     
  15. rejwan1

    rejwan1

    Joined:
    Jul 3, 2012
    Posts:
    40
    newstr1 and JoshPeterson like this.
  16. Wriggler

    Wriggler

    Joined:
    Jun 7, 2013
    Posts:
    131
    Nice work! Yes, I'm seeing these in UI particles too. Sounds like we have the same issue.

    Ben
     
    AliBuck likes this.
  17. newstr1

    newstr1

    Joined:
    Sep 22, 2017
    Posts:
    4
    Thank you very much for the hints, I also found a crash in the project when accessing to ParticleSystem.MinMaxCurve. Now I can at least continue testing the transition to 2022 without this functionality

    Special thanks for the bug report.
    I really hope that they will quickly fix this problem
     
  18. tomsseisums

    tomsseisums

    Joined:
    Oct 8, 2012
    Posts:
    37
    How do you guys even get the full stack trace for IL2CPP?

    With Logcat, all I get is this:
    Code (csharp):
    1. #00 pc 00000000004b96fc  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libunity.so (MemoryManager::VirtualAllocator::GetBlockInfoFromPointer(void const*)+12) (BuildId: 193a04e962461296)
    2. #01 pc 00000000004b45e8  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libunity.so (DualThreadAllocator<DynamicHeapAllocator>::Contains(void const*) const+64) (BuildId: 193a04e962461296)
    3. #02 pc 00000000004b8bbc  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libunity.so (MemoryManager::Deallocate(void*, MemLabelId const&, char const*, int)+216) (BuildId: 193a04e962461296)
    4. #03 pc 00000000052d6504  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    5. #04 pc 00000000060637b4  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    6. #05 pc 0000000006063700  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    7. #06 pc 00000000060ccf70  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    8. #07 pc 00000000061070f4  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    9. #08 pc 00000000060cceb8  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    10. #09 pc 00000000060c2498  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    11. #10 pc 00000000060be6bc  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    12. #11 pc 00000000000b67a8  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208) (BuildId: 39de735713a979219b391e7611970823)
    13. #12 pc 000000000005340c  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 39de735713a979219b391e7611970823)
     
    AliBuck likes this.
  19. tomsseisums

    tomsseisums

    Joined:
    Oct 8, 2012
    Posts:
    37
    Ah, okay, thanks to https://support.unity.com/hc/en-us/articles/115000292166-Symbolicate-Android-crash I found how to do it, turns out I have the same AnimationCurve issue:
    Code (CSharp):
    1. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #00 pc 00000000004b96fc (MemoryManager::VirtualAllocator::GetBlockInfoFromPointer(void const*) at ??:0)  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libunity.so (MemoryManager::VirtualAllocator::GetBlockInfoFromPointer(void const*)+12) (BuildId: 193a04e962461296)
    2. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #01 pc 00000000004b45e8 (DualThreadAllocator<DynamicHeapAllocator>::Contains(void const*) const at ??:0)  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libunity.so (DualThreadAllocator<DynamicHeapAllocator>::Contains(void const*) const+64) (BuildId: 193a04e962461296)
    3. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #02 pc 00000000004b8bbc (MemoryManager::Deallocate(void*, MemLabelId const&, char const*, int) at ??:0)  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libunity.so (MemoryManager::Deallocate(void*, MemLabelId const&, char const*, int)+216) (BuildId: 193a04e962461296)
    4. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #03 pc 00000000052d6504 (AnimationCurve_Internal_Destroy_m240B298D0A13EEC1652955C4BDCDBE9B7B2EE296 at C:/Users/tomss/Projects/ROLLHILL/rollhill/Library/Bee/artifacts/Android/il2cppOutput/cpp\UnityEngine.CoreModule.cpp:12656)  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    5. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #04 pc 00000000060637b4 (il2cpp::vm::Runtime::InvokeWithThrow(MethodInfo const*, void*, void**) at C:/Program Files/Unity/Hub/Editor/2022.3.2f1/Editor/Data/il2cpp/libil2cpp/vm\Runtime.cpp:604)  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    6. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #05 pc 0000000006063700 (il2cpp::vm::Runtime::Invoke(MethodInfo const*, void*, void**, Il2CppException**) at C:/Program Files/Unity/Hub/Editor/2022.3.2f1/Editor/Data/il2cpp/libil2cpp/vm\Runtime.cpp:590)  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    7. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #06 pc 00000000060ccf70 (il2cpp::gc::GarbageCollector::RunFinalizer(void*, void*) at C:/Program Files/Unity/Hub/Editor/2022.3.2f1/Editor/Data/il2cpp/libil2cpp/gc\GarbageCollector.cpp:178)  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    8. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #07 pc 00000000061070f4 (GC_invoke_finalizers at C:/Program Files/Unity/Hub/Editor/2022.3.2f1/Editor/Data/il2cpp/external/bdwgc/extra/..\finalize.c:1315)  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    9. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #08 pc 00000000060cceb8 (il2cpp::gc::GarbageCollector::InvokeFinalizers() at C:/Program Files/Unity/Hub/Editor/2022.3.2f1/Editor/Data/il2cpp/libil2cpp/gc\BoehmGC.cpp:460)  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    10. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #09 pc 00000000060c2498 (il2cpp::os::Thread::RunWrapper(void*) at C:/Program Files/Unity/Hub/Editor/2022.3.2f1/Editor/Data/il2cpp/libil2cpp/os\Thread.cpp:201)  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    11. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #10 pc 00000000060be6bc (il2cpp::os::ThreadImpl::ThreadStartWrapper(void*) at C:/Program Files/Unity/Hub/Editor/2022.3.2f1/Editor/Data/il2cpp/libil2cpp/os/Posix\ThreadImpl.cpp:123)  /data/app/~~ghQWRIe1Q9GgRlClVdSg1w==/<redacted>-2k7MKcJ8BTxxd_-Zp_54Eg==/lib/arm64/libil2cpp.so (BuildId: 14f2531e46eafca2)
    12. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #11 pc 00000000000b67a8 (libc.so not found)  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208) (BuildId: 39de735713a979219b391e7611970823)
    13. 2023.07.11 02:12:22.447 21946 22008 Error CRASH       #12 pc 000000000005340c (libc.so not found)  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 39de735713a979219b391e7611970823)
    14.  
    And looking into it, seems to be related with ParticleSystems/TrailRenderers (will continue debugging tomorrow). As disabling those, doesn't crash the game.
     
    AliBuck likes this.
  20. AliBuck

    AliBuck

    Joined:
    Aug 22, 2020
    Posts:
    30
    Thank you, guys! I was moving to the 2022.3.4 version in order for my iOS build to work, and it works only on this version somehow)
    But then I faced this bug on Android.
    Thanks to you I was able to find that one UI particle emitter that caused the problem! :D

    Before this thread I was desperate. In my case, I was referring to the particles that were hidden.
     
  21. newstr1

    newstr1

    Joined:
    Sep 22, 2017
    Posts:
    4
    I'll check again, but it seems that this crash disappeared in 2022.3.5f1 in my build
     
    kayy likes this.
  22. tomsseisums

    tomsseisums

    Joined:
    Oct 8, 2012
    Posts:
    37
    Same here, 2022.3.5f1 fixes the issue.
     
    kayy and newstr1 like this.
  23. Wriggler

    Wriggler

    Joined:
    Jun 7, 2013
    Posts:
    131
    I'm super late to the party, but I can confirm that 2022.3.5f1 fixes the issue for us too.

    Ben