Feedback Incremental GC feedback thread

We now have this deployed in production and it's working well. The issues we ran into & that I originally mentioned turned out to be unrelated, were instead related to UI onValueChanged events firing that previously didn't fire in object's state which was causing a stack overflow. I think the latest 2019.1x is actually catching it now even, instead of crashing.

Customer reports are mostly positive regarding the speed/performance improvements from enabling the incremental GC; though we've been making optimizations as well, so is difficult to bifurcate and attribute the reports, but overall no complaints here.

That said, is a win for sure and a good stride; next step, a more modern generational GC? A guy can hope! =D

Out of curiosity, and IIRC from reading this thread originally, the incremental is only in builds? Will it be coming to the editor at some point in the future? Right now it's probably my #1 issue with Unity: editor runs at ~50% performance of builds. Which means that debugging user-submitted issues via their save games = extremely painful.

Well, to clarify (and apologies for the slightly off-topic rant), really my #1 complaint with Unity is just performance in general. DOTS looks and seems great long-term, but it feels to be in varying states of beta / API change, and frankly it's still very unclear to me on what the best way [or IF there is even a workable/best way in Unity right now] to handle & render tons (100k+) of moving quads/2D within Unity -- and unfortunately we need something we can leverage much sooner than later.

Anyways, not to be sour at all; Rome wasn't built in a day and each step forward by the respective teams is great, welcomed, and appreciated. Definitely a very good and tangible step forward. Ty!

 

Is it Editor support enabled in any of the 19.3 alphas?

 

Jonas I'm not a unity dev, but a web dev who is nonetheless curious about spikes and stutters occurring in an ambition FPS unity game, Escape from Tarkov, which is under development, and doing a port from 2017 to 2018 soon.

My suspicions are that it may relate to GC, or possibly asset handling as it relates to LOD, again, as a non Unity dev, and a non-team member I don't have a lot to go on.

My question is simply this: Do you have any advice, or resources you'd recommend for Unity 2018 users relating to GC best practices, in lieu of using the incremental feature? Maybe advice on how Unity devs might diagnose the precise root of the issues?

My goal is to start a thread in the game's subreddit where the early users can share notes and experiences to possibly support the dev's debugging of the issue, and I'd love to include any of your insight on GC spikes especially.

 

Did you have a look at the "Optimizing garbage collection in Unity games" page already?
https://learn.unity.com/tutorial/fixing-performance-problems

 

I haven't, but I'll look into it. The reason I asked Jonas about ways one might hook into and improve 2018's GC functionality to bring it closer to 2019 is that I think that general advice would probably fall within the devs "what we've tried" list, while Jonas might be able to recommend patterns to mimic the performance 2019 gets.

 

As our WebGL application is severely limited by GC from reading many large JSON files continuously, I was wondering if there is any update on WebGL support for the Incremental GC?

 

When I enabled incremental gc, I've got gc spikes from garbage created on other threads. In other words - this doesn't happen in 'normal' mode, and it seems like every thread is responsible for own garbage, but with incremental, garbage from all my threads are collected at main thread, so for such case it's step backward unfortunately.

 

If it's global then something in Unity is not working as it should for a very long time and consistenly, because I never have GC spikes if garbage objects are created on other than main threads. Very easy to test out, just create thread that will do a lot of garbage over long time, and observe profiler - nothing will show up in terms of gc. So until now I was sure every spawned thread manages 'own garbage', beacause that's what Unity behaviour suggest, and it's been like this since I remember.

 

Could you post some code here how you make your threads? I'm guessing it's not in managed unity land?

 

It's buried a little under other API, but in the end it's normal C# new Thread(), so it's normal managed thread.

 

I was playing around with the experimental Incremental GC and I started noticing hard crashes (in the built player, but not in the editor). It took me a few days to realize it was linked to my turning on of this feature.

The feature itself seemed to work well for me (in the editor), but for whatever reason when I build the project (IL2CPP) these crashes begin.

I am building a multiplayer game and using sockets which is multi-threaded code. In the headless authoritive server it establishes a connection immediately upon startup (like literally the first frame).

I have been building the game for a couple of years but the hard crashes from memory errors just began in the built player a few days ago after turning on the incremental GC.

It seems to produce a crash (At times) and not at others -- which is particularly interesting, although it seems to be about 80% of the time on the headless server. The DMP file and crash logs seemed particularly useless in establishing what exactly is causing it.

I finally just disabled the Incremental GC and the memory allocation crashes in the built player disappeared. I wish I could provide you my project for testing but honestly the project is huge.

I am currently using 2019.2.6f1

 

Does 2020 have incremental GC enabled for the Editor?

 

iàm currently on 2019.1 but i read on this coument that incremental garbage collection is working on ps4, switch etc.. from .2, are this correct

https://docs.unity3d.com/Manual/UnderstandingAutomaticMemoryManagement.html

exactly say this

• Ability to disable garbage collection on Mono and IL2CPP scripting backends added in Unity 2018.3
• Added exerimental Incremental Garbage Collection feature added in Unity 2019.1
• Added support for Incremental Garbage Collection on additional platforms: PS4, XBox One, Nintendo Switch, and the Unity Editor. 2019.2

 

We've tested the incremental GC in our new app version and the crash rates went crazy, specially on iOS.
Pretty much every call stack was like this:

Code (CSharp):

1. 0   libsystem_kernel.dylib             0x00000001bcd55c94 __psynch_cvwait
2. 1   tycoon                             0x00000001059344dc il2cpp::os::posix::PosixWaitObject::Wait(unsigned int, bool)
3. 2   tycoon                             0x000000010594b4bc il2cpp::vm::Monitor::TryWait(Il2CppObject*, unsigned int)
4. 3   tycoon                             0x0000000107054108 ManualResetEventSlim_Wait_mBBC47852C86E2A3D08FADAF3DE0588A2CE720B2F
5. 4   tycoon                             0x0000000107065888 Task_WaitAllBlockingCore_m18DAF42FBD4D325F72C883D67DB9F387566F88CE
6. 5   tycoon                             0x0000000107064d94 Task_WaitAll_m09EB068F881967FB91C8A221832F909BA3F1D00B
7. 6   tycoon                             0x00000001070644a0 Task_WaitAll_m3D33138B9A02E2F739209DC77AF3441382C5B98F
8. 7   tycoon                             0x00000001070643a8 Task_WaitAll_m7DEFF8B98DA926238FE40A54AA48FB0E3CAD1C47

So we released a new version disabling incremental GC and the crashes seem to be gone.
Using Unity 2019.2.12f1.

 

Is there a way to know how much garbage has been created in the current frame?
Or better, is there a way to know how much garbage created since the last call to a function ('GetGarbageSinceLastCall()' for example)?

Using the editor to profile isn't so useful because the editor has a devastating impact on performances.
In addition, the editor itself generates garbage for some very standard things.
And in addition, the editor will indicate some garbage generated in a method, under the form of 'GC.Alloc()'. But it's not that useful to know where in the method the garbage is generated.
With a 'GetGarbageSinceLastCall()' method we could use dichotomy to find out the culprit.

 

Having such method would be really useful!

 

I have a question. I am manually unloading streamed terrain game objects by destroying them and then calling Resources.UnloadUnusedAssets, which I understand calls GC collect internally. I am seeing spikes still even with the incremental GC feature on.

It seems that if using UnloadUnusedAssets, the incremental GC is not used? Is that correct? Is the incremental GC only for mono objects? Will Unity specific assets like the assets associated with a Terrain not benefit from the incremental GC?

 

@jonas-echterhoff
Just reread the thread and noticed you already said UnloadUnusedAssets will not use the incremental GC. Are there any plans to change this? It's nice to have the new GC but if unloading native Unity Assets doesn't make use of the same multi frame strategy, that kind of sucks. It would solve a lot of peoples issues with streaming terrain.

Maybe you can offer the best strategy for unloading a terrain, or other large scenes that contain a bunch of Native Unity Assets?

 

Hi, I'm using Unity 2019.3.7f1 after enabling Incremental GC the performance improvement is pretty great but a large number of Radeon users are getting crashes the log for the crash show :

Code (CSharp):

1. Thread 4 (crashed)
2. 0   ntdll                              0x00007ffec86dcc14 ZwWaitForMultipleObjects
3. 1   KERNELBASE                         0x00007ffec63280f7 WaitForMultipleObjectsEx
4. 2   KERNELBASE                         0x00007ffec6327fde WaitForMultipleObjects
5. 3   UnityPlayer                        0x00007ffe5fad67ad ?HandleCrash@ExternalCrashHandler@winutils@@AEAAXKKPEBDPEAU_CONTEXT@@PEAU_EXCEPTION_RECORD@@_N@Z
6. 4   UnityPlayer                        0x00007ffe5fad6852 ?HandleCrash@ExternalCrashHandler@winutils@@QEAA_NKKPEAU_EXCEPTION_POINTERS@@@Z
7. 5   UnityPlayer                        0x00007ffe5fae2df8 ?ProcessInternalCrash@winutils@@YAHPEAU_EXCEPTION_POINTERS@@_N@Z
8. 6   KERNELBASE                         0x00007ffec63d006a UnhandledExceptionFilter
9. 7   ntdll                              0x00007ffec86e4b32 RtlUserThreadStart$filt$0
10. 8   ntdll                              0x00007ffec86cc6d6 _C_specific_handler
11. 9   ntdll                              0x00007ffec86e121f RtlpExecuteHandlerForException
12. 10  ntdll                              0x00007ffec86aa289 RtlDispatchException
13. 11  ntdll                              0x00007ffec86dfe8e KiUserExceptionDispatch
14. 12  UnityPlayer                        0x00007ffe5fc37c91 ??$WriteLineVertex@$0A@@@YAXAEAPEAEAEBUfloat4x4@math@@AEBU_float3@1@AEBVColorRGBA32@@AEBU_float1@1@MAEBU_float2@1@@Z
15. 13  UnityPlayer                        0x00007ffe602eb574 BuildParticleLineSegment<0>
16. 14  UnityPlayer                        0x00007ffe602eb138 BuildParticleLine<0>
17. 15  UnityPlayer                        0x00007ffe6032b281 ?RenderJobCommon@ParticleSystemTrailGeometryJob@@CAXAEAV1@PEAXI@Z
18. 16  UnityPlayer                        0x00007ffe6032a0d0 ?RenderJob@ParticleSystemTrailGeometryJob@@CAXPEAUSharedGeometryJobData@@I@Z
19. 17  UnityPlayer                        0x00007ffe5fd058e8 ?Exec@JobQueue@@AEAAHPEAUJobInfo@@_JH@Z
20. 18  UnityPlayer                        0x00007ffe5fd0694c ?Steal@JobQueue@@AEAAHPEAVJobGroup@@PEAUJobInfo@@_JH_N@Z
21. 19  UnityPlayer                        0x00007ffe5fd05a17 ?ExecuteJobFromQueue@JobQueue@@AEAA_NXZ
22. 20  UnityPlayer                        0x00007ffe5fd05d27 ?ProcessJobs@JobQueue@@AEAAXPEAUThreadInfo@1@PEAX@Z
23. 21  UnityPlayer                        0x00007ffe5fd06e50 ?WorkLoop@JobQueue@@CAPEAXPEAX@Z
24. 22  UnityPlayer                        0x00007ffe5fdef648 ?RunThreadWrapper@Thread@@CAKPEAX@Z
25. 23  KERNEL32                           0x00007ffec67e7bd4 BaseThreadInitThunk
26. 24  ntdll                              0x00007ffec86aced1 RtlUserThreadStart
27. 25  ntdll                              0x00007ffec86aced1 RtlUserThreadStart

Is this a know issue? is there any workaround?

 

Hi, we have the worst-case scenario that we get crashes, connect to the Garbage Collection system, with both the new experimental incremental GC and the classic GC. With the new incremental system, the amount of crashes has skyrocketed, it is always on non-main thread, and happens randomly throughout the app. This is specifically an iOS app. Here are some examples:

Code (CSharp):

1. Thread 46 name:
2. Thread 46 Crashed:
3. 0   ios                               0x0000000105aca4d4 il2cpp::vm::MetadataCache::GetTypeInfoFromTypeDefinitionIndex(int) + 48 (MetadataCache.cpp:1015)
4. 1   ios                               0x0000000105ac68e8 il2cpp::vm::InitLocked(Il2CppClass*, il2cpp::os::FastAutoLock const&) + 92 (Class.cpp:1405)
5. 2   ios                               0x0000000105ac68e8 il2cpp::vm::InitLocked(Il2CppClass*, il2cpp::os::FastAutoLock const&) + 92 (Class.cpp:1405)
6. 3   ios                               0x0000000105ac4f40 il2cpp::vm::Class::Init(Il2CppClass*) + 56 (Class.cpp:1473)
7. 4   ios                               0x0000000105ac588c il2cpp::vm::Class::IsAssignableFrom(Il2CppClass*, Il2CppClass*) + 68 (Class.cpp:586)
8. 5   ios                               0x0000000105aa77c0 il2cpp::vm::Object::IsInst(Il2CppObject*, Il2CppClass*) + 48 (Object.cpp:245)
9. 6   ios                               0x00000001072da758 MoveNextRunner_InvokeMoveNext_mDDBDFE3402137780DC55FEB4966D21E252679CED + 84 (il2cpp-codegen-il2cpp.h:187)
10. 7   ios                               0x00000001073b5d2c ContextCallback_Invoke_m76E65E7A67AA99858554F451E0F78E22B6478998 + 876 (ClassInlines.h:0)
11. 8   ios                               0x00000001073b6eac ExecutionContext_RunInternal_m5BF955CE8B04D9A7C959B9011579CC0FABD5FC56 + 324 (mscorlib20.cpp:22663)
12. 9   ios                               0x00000001072da60c MoveNextRunner_Run_m58F5A88A10853D5B1999E8B3A1CA15A55385C59F + 216 (mscorlib12.cpp:28950)
13. 10  ios                               0x000000010729d0a4 Action_Invoke_mC8D676E5DDF967EC5D23DD0E96FB52AA499817FD + 492 (ClassInlines.h:0)
14. 11  ios                               0x00000001073bf9a0 AwaitTaskContinuation_RunOrScheduleAction_mE8B713E233CB78D3973E7E3501DEE4935E553101 + 164 (mscorlib20.cpp:32194)
15. 12  ios                               0x00000001073c60c0 Task_FinishContinuations_m6BBB58CFA80FB99D16972B13ECC41B734475EFCD + 384 (mscorlib20.cpp:40338)
16. 13  ios                               0x0000000106b3a9b4 Task_1_TrySetResult_m38F5C35F41BC393435AC1CF161290BA66B27D3F6_gshared + 144 (Generics64.cpp:14056)
17. 14  ios                               0x0000000106b32068 FromAsyncTrimPromise_1_Complete_m8C4B449E2F0AB2F7DBEB3545274E70FC2723020E_gshared + 156 (Generics64.cpp:8583)
18. 15  ios                               0x000000010739e20c AsyncCallback_Invoke_m1830E56CD41BDD255C144AA16A9426EEE301617C + 876 (ClassInlines.h:0)
19. 16  ios                               0x00000001073d37fc WaitCallback_Invoke_mB6A858A1792B8E0DE526C3C157624C1A59EEFA16 + 728 (ClassInlines.h:0)
20. 17  ios                               0x00000001073d1100 ThreadPoolWorkQueue_Dispatch_mCDF7415E4C9D02B34761CAE8EA15CD33DDF85ADF + 764 (mscorlib21.cpp:176)
21. 18  ios                               0x0000000104ae2e14 RuntimeInvoker_FalseSByte_t9070AEA2966184235653CB9B4D33B149CDA831DF(void (*)(), MethodInfo const*, void*, void**) + 32 (Il2CppInvokerTable.cpp:63842)
22. 19  ios                               0x0000000105a97da8 worker_thread(void*) + 276 (ThreadPoolWorkerThread.cpp:252)
23. 20  ios                               0x0000000105abacc0 il2cpp::vm::ThreadStart(void*) + 80 (Thread.cpp:698)
24. 21  ios                               0x0000000105a990f8 il2cpp::os::Thread::RunWrapper(void*) + 88 (Thread.cpp:175)
25. 22  ios                               0x0000000105a9b458 il2cpp::os::ThreadImpl::ThreadStartWrapper(void*) + 40 (ThreadImpl.cpp:105)
26. 23  libsystem_pthread.dylib           0x00000001a971fd98 _pthread_start + 156 (pthread.c:896)
27. 24  libsystem_pthread.dylib           0x00000001a972374c thread_start + 8

Code (CSharp):

1.  

Code (CSharp):

1. Thread 47 name:
2. Thread 47 Crashed:
3. 0   ios                               0x0000000105d60f1c il2cpp::vm::Class::Init(Il2CppClass*) + 20 (Class.cpp:1470)
4. 1   ios                               0x0000000105d6188c il2cpp::vm::Class::IsAssignableFrom(Il2CppClass*, Il2CppClass*) + 68 (Class.cpp:586)
5. 2   ios                               0x0000000105d6188c il2cpp::vm::Class::IsAssignableFrom(Il2CppClass*, Il2CppClass*) + 68 (Class.cpp:586)
6. 3   ios                               0x0000000105d437c0 il2cpp::vm::Object::IsInst(Il2CppObject*, Il2CppClass*) + 48 (Object.cpp:245)
7. 4   ios                               0x0000000107576758 MoveNextRunner_InvokeMoveNext_mDDBDFE3402137780DC55FEB4966D21E252679CED + 84 (il2cpp-codegen-il2cpp.h:187)
8. 5   ios                               0x0000000107651d2c ContextCallback_Invoke_m76E65E7A67AA99858554F451E0F78E22B6478998 + 876 (ClassInlines.h:0)
9. 6   ios                               0x0000000107652eac ExecutionContext_RunInternal_m5BF955CE8B04D9A7C959B9011579CC0FABD5FC56 + 324 (mscorlib20.cpp:22663)
10. 7   ios                               0x000000010757660c MoveNextRunner_Run_m58F5A88A10853D5B1999E8B3A1CA15A55385C59F + 216 (mscorlib12.cpp:28950)
11. 8   ios                               0x00000001075390a4 Action_Invoke_mC8D676E5DDF967EC5D23DD0E96FB52AA499817FD + 492 (ClassInlines.h:0)
12. 9   ios                               0x000000010765b9a0 AwaitTaskContinuation_RunOrScheduleAction_mE8B713E233CB78D3973E7E3501DEE4935E553101 + 164 (mscorlib20.cpp:32194)
13. 10  ios                               0x00000001076620c0 Task_FinishContinuations_m6BBB58CFA80FB99D16972B13ECC41B734475EFCD + 384 (mscorlib20.cpp:40338)
14. 11  ios                               0x0000000106dd69b4 Task_1_TrySetResult_m38F5C35F41BC393435AC1CF161290BA66B27D3F6_gshared + 144 (Generics64.cpp:14056)
15. 12  ios                               0x0000000106dce068 FromAsyncTrimPromise_1_Complete_m8C4B449E2F0AB2F7DBEB3545274E70FC2723020E_gshared + 156 (Generics64.cpp:8583)
16. 13  ios                               0x000000010763a20c AsyncCallback_Invoke_m1830E56CD41BDD255C144AA16A9426EEE301617C + 876 (ClassInlines.h:0)
17. 14  ios                               0x000000010766f7fc WaitCallback_Invoke_mB6A858A1792B8E0DE526C3C157624C1A59EEFA16 + 728 (ClassInlines.h:0)
18. 15  ios                               0x000000010766d100 ThreadPoolWorkQueue_Dispatch_mCDF7415E4C9D02B34761CAE8EA15CD33DDF85ADF + 764 (mscorlib21.cpp:176)
19. 16  ios                               0x0000000104d7ee14 RuntimeInvoker_FalseSByte_t9070AEA2966184235653CB9B4D33B149CDA831DF(void (*)(), MethodInfo const*, void*, void**) + 32 (Il2CppInvokerTable.cpp:63842)
20. 17  ios                               0x0000000105d33da8 worker_thread(void*) + 276 (ThreadPoolWorkerThread.cpp:252)
21. 18  ios                               0x0000000105d56cc0 il2cpp::vm::ThreadStart(void*) + 80 (Thread.cpp:698)
22. 19  ios                               0x0000000105d350f8 il2cpp::os::Thread::RunWrapper(void*) + 88 (Thread.cpp:175)
23. 20  ios                               0x0000000105d37458 il2cpp::os::ThreadImpl::ThreadStartWrapper(void*) + 40 (ThreadImpl.cpp:105)
24. 21  libsystem_pthread.dylib           0x00000001b21c7d98 _pthread_start + 156 (pthread.c:896)
25. 22  libsystem_pthread.dylib           0x00000001b21cb74c thread_start + 8

Code (CSharp):

1. Thread 38 name:
2. Thread 38 Crashed:
3. 0   ios                               0x0000000103d4ad4c RaiseInvalidCastException(Il2CppObject*, Il2CppClass*) + 20 (il2cpp-codegen-il2cpp.cpp:450)
4. 1   ios                               0x00000001052ff1d8 U3CU3Ec_U3C_cctorU3Eb__309_8_mA9F0B14FEA60E5CA4D29CDF2F8BBABE4CEDEDB5F + 272 (il2cpp-codegen-il2cpp.h:204)
5. 2   ios                               0x00000001052ff1d8 U3CU3Ec_U3C_cctorU3Eb__309_8_mA9F0B14FEA60E5CA4D29CDF2F8BBABE4CEDEDB5F + 272 (il2cpp-codegen-il2cpp.h:204)
6. 3   ios                               0x00000001052c2854 IOAsyncCallback_Invoke_mB95F7E7F0E8326CE5364A30F42FC1073B0AB2D8B + 728 (ClassInlines.h:0)
7. 4   ios                               0x00000001056a1110 ThreadPoolWorkQueue_Dispatch_mCDF7415E4C9D02B34761CAE8EA15CD33DDF85ADF + 764 (mscorlib21.cpp:176)
8. 5   ios                               0x0000000102db2e24 RuntimeInvoker_FalseSByte_t9070AEA2966184235653CB9B4D33B149CDA831DF(void (*)(), MethodInfo const*, void*, void**) + 32 (Il2CppInvokerTable.cpp:63842)
9. 6   ios                               0x0000000103d67db8 worker_thread(void*) + 276 (ThreadPoolWorkerThread.cpp:252)
10. 7   ios                               0x0000000103d8acd0 il2cpp::vm::ThreadStart(void*) + 80 (Thread.cpp:698)
11. 8   ios                               0x0000000103d69108 il2cpp::os::Thread::RunWrapper(void*) + 88 (Thread.cpp:175)
12. 9   ios                               0x0000000103d6b468 il2cpp::os::ThreadImpl::ThreadStartWrapper(void*) + 40 (ThreadImpl.cpp:105)
13. 10  libsystem_pthread.dylib           0x00000001a6b99d8c _pthread_start + 156 (pthread.c:896)
14. 11  libsystem_pthread.dylib           0x00000001a6b9d76c thread_start + 8

Code (CSharp):

1.  

Code (CSharp):

1. Thread 44 name:
2. Thread 44 Crashed:
3. 0   ios                               0x0000000105f3da5c il2cpp::os::FastMutex::Lock() + 0 (Mutex.cpp:65)
4. 1   ios                               0x0000000105f343d4 il2cpp::icalls::mscorlib::System::Threading::Thread::GetState40(Il2CppInternalThread*) + 28 (Mutex.h:78)
5. 2   ios                               0x000000010786a194 Task_FinishContinuations_m6BBB58CFA80FB99D16972B13ECC41B734475EFCD + 176 (mscorlib20.cpp:40305)
6. 3   ios                               0x0000000106fe23c8 Task_1_TrySetResult_m4FE4E07EBB0BA224341A4946FE2C4A813BD8AF64_gshared + 156 (Generics64.cpp:16177)
7. 4   ios                               0x0000000106fdad40 TaskFactory_1_FromAsyncCoreLogic_m0ABABC75EABF797DAA4144DCEA5A0D037EA6E7F6_gshared + 456 (Generics64.cpp:11807)
8. 5   ios                               0x000000010784231c AsyncCallback_Invoke_m1830E56CD41BDD255C144AA16A9426EEE301617C + 728 (ClassInlines.h:0)
9. 6   ios                               0x0000000104f86c68 RuntimeInvoker_TrueVoid_t22962CB4C05B1D89B55A6E1139F0E87A90987017_RuntimeObject(void (*)(), MethodInfo const*, void*, void**) + 32 (Il2CppInvokerTable.cpp:63681)
10. 7   ios                               0x0000000105f67bb0 il2cpp::vm::Runtime::Invoke(MethodInfo const*, void*, void**, Il2CppException**) + 116 (Runtime.cpp:542)
11. 8   ios                               0x0000000105f332ac il2cpp::icalls::mscorlib::System::Runtime::Remoting::Messaging::AsyncResult::Invoke(Il2CppObject*) + 212 (AsyncResult.cpp:60)
12. 9   ios                               0x00000001078752a4 ThreadPoolWorkQueue_Dispatch_mCDF7415E4C9D02B34761CAE8EA15CD33DDF85ADF + 764 (mscorlib21.cpp:176)
13. 10  ios                               0x0000000104f87210 RuntimeInvoker_FalseSByte_t9070AEA2966184235653CB9B4D33B149CDA831DF(void (*)(), MethodInfo const*, void*, void**) + 32 (Il2CppInvokerTable.cpp:63842)
14. 11  ios                               0x0000000105f3c198 worker_thread(void*) + 276 (ThreadPoolWorkerThread.cpp:252)
15. 12  ios                               0x0000000105f5f0b0 il2cpp::vm::ThreadStart(void*) + 80 (Thread.cpp:698)
16. 13  ios                               0x0000000105f3d4e8 il2cpp::os::Thread::RunWrapper(void*) + 88 (Thread.cpp:175)
17. 14  ios                               0x0000000105f3f848 il2cpp::os::ThreadImpl::ThreadStartWrapper(void*) + 40 (ThreadImpl.cpp:105)
18. 15  libsystem_pthread.dylib           0x00000001b4e0dd8c _pthread_start + 156 (pthread.c:896)
19. 16  libsystem_pthread.dylib           0x00000001b4e1176c thread_start + 8

Code (CSharp):

1. Thread 43 name:
2. Thread 43 Crashed:
3. 0   ios                               0x00000001050ed77c il2cpp::os::FastMutex::Lock() + 0 (Mutex.cpp:65)
4. 1   ios                               0x000000010510e6e4 il2cpp::vm::Thread::SetState(Il2CppThread*, il2cpp::vm::ThreadState) + 40 (Mutex.h:78)
5. 2   ios                               0x00000001050e44dc il2cpp::icalls::mscorlib::System::Threading::WaitHandle::Wait_internal(void**, int, bool, int) + 60 (Thread.h:145)
6. 3   ios                               0x0000000106a28270 WaitHandle_WaitOneNative_mC25327F2B99DBB404B62FD48CFCBDB3244F82434 + 152 (mscorlib21.cpp:24186)
7. 4   ios                               0x0000000106a28138 WaitHandle_InternalWaitOne_m14CF12240D30C25A6C34683080C5A0D982786303 + 116 (mscorlib21.cpp:23513)
8. 5   ios                               0x0000000105a0c314 Dispatcher_Run_TisRuntimeObject_m587BE881FF5FB842675F19D6FD693CC7E1A94010_gshared + 436 (GenericMethods16.cpp:51)
9. 6   ios                               0x000000010590a974 FirebaseApp_CreateAndTrack_m9432CF67F169FAFC2D57F7C8E2460CBE174CB6F7 + 368 (Firebase.App.cpp:8694)
10. 7   ios                               0x00000001058d0764 Crashalytics_U3CStartU3Eb__12_0_m68E0312F9CD943568CD663CBEE3B3CE7746E7C73 + 288 (Core9.cpp:23445)
11. 8   ios                               0x0000000105b2e6a8 Action_1_Invoke_mB86FC1B303E77C41ED0E94FC3592A9CF8DA571D5_gshared + 728 (ClassInlines.h:0)
12. 9   ios                               0x0000000106a1a64c Task_Execute_mF91032F33896912C3A3CC6A568220EBC5D439CFF + 152 (mscorlib20.cpp:34)
13. 10  ios                               0x0000000106a09e3c ContextCallback_Invoke_m76E65E7A67AA99858554F451E0F78E22B6478998 + 876 (ClassInlines.h:0)
14. 11  ios                               0x0000000106a0afbc ExecutionContext_RunInternal_m5BF955CE8B04D9A7C959B9011579CC0FABD5FC56 + 324 (mscorlib20.cpp:22663)
15. 12  ios                               0x0000000106a1ad60 Task_ExecuteWithThreadLocal_mFF23F3F9C0796B0EE2AC70CB51AD7D2A2867D733 + 388 (mscorlib20.cpp:39007)
16. 13  ios                               0x0000000106a1ab78 Task_ExecuteEntry_mA04E6FA3370CA2AB19B6AB209E44E993B14621F1 + 300 (mscorlib20.cpp:38875)
17. 14  ios                               0x0000000106a25210 ThreadPoolWorkQueue_Dispatch_mCDF7415E4C9D02B34761CAE8EA15CD33DDF85ADF + 764 (mscorlib21.cpp:176)
18. 15  ios                               0x0000000104136f24 RuntimeInvoker_FalseSByte_t9070AEA2966184235653CB9B4D33B149CDA831DF(void (*)(), MethodInfo const*, void*, void**) + 32 (Il2CppInvokerTable.cpp:63842)
19. 16  ios                               0x00000001050ebeb8 worker_thread(void*) + 276 (ThreadPoolWorkerThread.cpp:252)
20. 17  ios                               0x000000010510edd0 il2cpp::vm::ThreadStart(void*) + 80 (Thread.cpp:698)
21. 18  ios                               0x00000001050ed208 il2cpp::os::Thread::RunWrapper(void*) + 88 (Thread.cpp:175)
22. 19  ios                               0x00000001050ef568 il2cpp::os::ThreadImpl::ThreadStartWrapper(void*) + 40 (ThreadImpl.cpp:105)
23. 20  libsystem_pthread.dylib           0x00000001ba931d8c _pthread_start + 156 (pthread.c:896)
24. 21  libsystem_pthread.dylib           0x00000001ba93576c thread_start + 8

Whereas with the non-experimental, we get less frequent (overall) crashes, however, they happen very regularly when the app has gone into the background for a little while, and then is brought into the foreground (this background -> foreground crash doesn't happen with the experimental). The following has happened 23 times in our last internal release/test version (reported by Crashlytics).

Code (CSharp):

1. Crashed: com.apple.main-thread
2. 0  ios                            0x1051022c0 il2cpp::vm::LivenessState::AddProcessObject(Il2CppObject*, il2cpp::vm::LivenessState*) + 335 (Liveness.cpp:335)
3. 1  ios                            0x1051020d8 il2cpp::vm::LivenessState::TraverseArray(Il2CppArray*, il2cpp::vm::LivenessState*) + 323 (Liveness.cpp:323)
4. 2  ios                            0x105101e5c il2cpp::vm::LivenessState::TraverseObjects() + 143 (Liveness.cpp:143)
5. 3  ios                            0x105102734 il2cpp::vm::Liveness::FromStatics(void*) + 492 (Liveness.cpp:492)
6. 4  ios                            0x1048aa3ac GarbageCollectSharedAssets(bool, bool) + 19 (TimeHelper.h:19)
7. 5  ios                            0x1048b946c UnloadUnusedAssetsOperation::IntegrateMainThread() + 49 (UnloadUnusedAssetsOperation.cpp:49)
8. 6  ios                            0x1048b88dc PreloadManager::UpdatePreloadingSingleStep(PreloadManager::UpdatePreloadingFlags, int) + 392 (PreloadManager.cpp:392)
9. 7  ios                            0x1048b8fe0 PreloadManager::UpdatePreloading() + 518 (PreloadManager.cpp:518)
10. 8  ios                            0x1048ab224 ExecutePlayerLoop(NativePlayerLoopSystem*) + 277 (PlayerLoop.cpp:277)
11. 9  ios                            0x1048ab258 ExecutePlayerLoop(NativePlayerLoopSystem*) + 295 (PlayerLoop.cpp:295)
12. 10 ios                            0x1048ab44c PlayerLoop() + 356 (PlayerLoop.cpp:356)
13. 11 ios                            0x104c8ec80 UnityPlayerLoopImpl(bool) + 276 (LibEntryPoint.mm:276)
14. 12 ios                            0x104035908 UnityRepaint + 280 (UnityAppController+Rendering.mm:280)
15. 13 ios                            0x1040357e4 -[UnityAppController(Rendering) repaintDisplayLink] + 72 (UnityAppController+Rendering.mm:72)
16. 14 QuartzCore                     0x1b7c15f24 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 628
17. 15 QuartzCore                     0x1b7ce4608 display_timer_callback(__CFMachPort*, void*, long, void*) + 268
18. 16 CoreFoundation                 0x1b10e1dac __CFMachPortPerform + 176
19. 17 CoreFoundation                 0x1b110c7c4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 60
20. 18 CoreFoundation                 0x1b110be90 __CFRunLoopDoSource1 + 448
21. 19 CoreFoundation                 0x1b1106ac8 __CFRunLoopRun + 2144
22. 20 CoreFoundation                 0x1b1105f40 CFRunLoopRunSpecific + 480
23. 21 GraphicsServices               0x1bb396534 GSEventRunModal + 108
24. 22 UIKitCore                      0x1b5291580 UIApplicationMain + 1940
25. 23 ios                            0x10402d5fc main + 40 (main.mm:40)
26. 24 libdyld.dylib                  0x1b0f84e18 start + 4

We are using 2019.2.12f1 and this is a bit of a nightmare, we are having to have versions of our software on the market which we know crashes and there doesn't appear to be anything we can do to fix it. Can anyone at Unity help us with this?

 

Does any other devs have experience with incremental GC? If we would upgrade from 2017.4 than it would be mostly for that feature, but if it does make crashes more frequently it is critically bad.

 

We'd be interested to hear from more devs, the above crashes I have reported is just part of the long list of crash reports caused by this issue. For us, it is by far the biggest crash we receive both internally and externally (more or less the only crash). Due to the nature of it, we can't really give a repo, it just happens anywhere and everywhere - the best we can do is report in threads like this, and as you can see, there is no response, no support, it does make it very hard to know what the best thing to do is. Perhaps you could try making a copy of your project, upgrading and running and just see how it goes? For some people, it seems to work well. I suspect it depends on how your app uses (loads/deletes/etc.) resources - our all is just a single scene which has content loaded in and out at runtime, whereas some apps just have all the assets in the scene then change the scene on level load so are possibly a lot simpler.

 

I'm curious if there's a way to identify a given crash as being the result of the incremental GC, versus being any other kind of crash.

I've been getting a few of the crash this same crash, caused by the following:

Code (CSharp):

1.  

I see a lot of memory management going on in the stack trace, but it's not clear to me whether that indicates it has anything to do with the garbage collector, or whether this is just a memory issue outside the scope of GC.

 

Hi, just wanted to make sure if it's a correct behaviour from the Incremental GC or not, but I'm getting spikes of around 10ms while there is never any GC alloc during the GC collect. Should I fill a bug report for it?

 

Just wanted to drop out that after moving from 2017 LTS to 2019 LTS our server application is much more stable (no single crash for months already, while they were happening one-twice per week), and incremental GC is a total gamechanger for the performance.

Obviously we have other issues about the transition, but Incremental GC did miracles in our case.

 

Just came to say Incremental GC works great, no crashes, no gfx.waitforpresent issues, no nothing, just steady 60 fps. I even when i have to instantiate something huge because reasons it doesn't go below 30 fps.

 

Hey, are there any plans to make incremental GC the default in new Unity projects, if they can be beneficial in most projects that don't have too many changes between frames? Also -- if I use incremental GC, does that kind of mean that it might be alright to use allocations like LINQ or closures in per-frame code, instead of trying to keep it at zero-allocations to prevent hiccups?

Thank you

 

It's the default. At least in 2020 LTS.

If you're targeting 25 or 30FPS maybe, but in general: no. Incremental GC has an overhead by just itself. If you introduce large amount of memory to process, the time to do that even in time-slicing will be just too big.
The best course of action still is using allocation-free code as much as possible.

 

Not sure it's possible, but if it's not: I'd like to suggest being able to also manually specify at which frames the GC runs.
I'd like to:
- In general, run the incremental GC automatically, yet
- be able to trigger an incremental GC ln specific frames and
- be able to block specific frames from being used for GC.
EDIT:
It's solved:
https://forum.unity.com/threads/manually-trigger-incremental-gc.1265225/#post-8033711

 

We set PlayerSetting.gcIncremental=true，then build a Android apk.But incremental gc do not work, and
isIncremental is false.

At Editor, it is right, but run at phone, it is wrong.

In build log, we find "--incremental-g-c-time-slice=3" as il2cpp arguments.

I am using 2019.4.8f1

Wait for Help, Thanks.

 

I find the reason, because "both-armv7-and-arm64-selected", https://issuetracker.unity3d.com/is...ing-an-apk-with-both-armv7-and-arm64-selected

Fixed in 2020.2.X

 

Got critical bug of 'IncrementalGC' with "GarbageCollector.GCMode = GarbageCollector.Mode.Disabled" on Unity 2019.4.40. Platform: Xbox(XDK).
In main menu of the game GC is enabled, when loaded gameplay level GC is sets to disabled. And after that fps start slowly degrade down to 0. Profiler show that problem with: "GarbageCollector.CollectIncremental".
It looks like this one case: http://dotsquid.com/2020/12/18/how-i-broke-incremental-gc-in-unity/

 

Since 2019.4 is no longer supported, you won't get a bugfix unless you're willing to upgrade to a newer Unity version.

(Also, Microsoft no longer accepts submissions for new games using XDK)

 

2019.4 is still in LTS until they ship 2022 LTS, in about 6 months at minimum, so it's very much supported. It's not getting new features since it's in LTS, but "not crashing" isn't a new feature

 

Is that really the case? Unity Technologies wrote 2019.4.40f1 is the last release of the 2019.4 stream:

https://forum.unity.com/threads/unity-lts-release-announcements.529171/page-4#post-8211849

 

Oh, yeah, whoops, I'm dumb! Two active LTS versions, not three. My bad!

 

Ok, will do it.

 

That's not new game.

 

I see. Your options are limited then. Short of working out some sort of hacky workaround, the most viable option is to disable incremental GC, then identify and optimize any outstanding GC spikes.

 

Already did like you said: disable incremental GC and clean all GC spikes. But we also must fix this Unity Engine bug for happy future all of us .

 

This is very interesting.
I'm using someone else's game that uses Garbage Collector in my project.
I have problems with WebGL as it is not yet supported.
In the browser after WebGL compilation, some game buttons do not work.
I get the browser errors:
project.framework.js.gz:3 InvalidOperationException: Garbage collection mode setting is not supported on this platform
In the Unity editor (2021.3.1f1 ), the "Use incremental GC" box cannot be checked yet
However, when I delete my Garbage Collector file, which I show later, and the references in the files, This box is automatically checked in the Unity Editor (2021.3.1f1 )
It's OK to remove my Garbage Collector files and point references ( StarGame, PauseGame, ResumeGame, GameOver )

Code (CSharp):

1.  
2. using System;
3. using UnityEngine;
4. using UnityEngine.Scripting;
5.  
6. public static class GarbageCollectionManager
7. {
8.     public static void DisableGC()
9.     {
10.         #if !UNITY_EDITOR
11.         GarbageCollector.GCMode = GarbageCollector.Mode.Disabled;
12.         #endif
13.     }
14.  
15.     public static void CollectGarbage()
16.     {
17.         #if !UNITY_EDITOR
18.         GarbageCollector.GCMode = GarbageCollector.Mode.Enabled;
19.         GC.Collect();
20.         GarbageCollector.GCMode = GarbageCollector.Mode.Disabled;
21.         #endif
22.     }
23. }
24.  

Thank you, I hope you can give me some idea, this is very confusing for me, I have read the Unity documentation, but I don't understand
####3
These are the references to Garbage Collector

Code (CSharp):

1. public void StartGame()
2.     {
3.         GarbageCollectionManager.CollectGarbage();
4.         Time.timeScale = 1f;
5.         MenuPanel.SetActive(false);
6.         TutorialText.gameObject.SetActive(true);
7.         _spawner.Spawner();
8.         TheGlobals.playingMode = true;
9.         StartCoroutine(FadeoutTutorial());
10.         TheGlobals.sManager.bgMusic.volume = 0.6f;
11.     }

Code (CSharp):

1. public void PauseGame()
2.     {
3.         GarbageCollectionManager.CollectGarbage();
4.         PausePanel.SetActive(true);
5.         highScoreTextPause.text = "High Score : " + GamePreferences.HighScore.ToString();
6.         Time.timeScale = 0f;
7.     }
8.  
9.     public void ResumeGame()
10.     {
11.         GarbageCollectionManager.CollectGarbage();
12.         PausePanel.SetActive(false);
13.         StartCoroutine(WaitToResume());
14.     }

Code (CSharp):

1. public void GameOver()
2.     {
3.         //GarbageCollectionManager.CollectGarbage();
4.         TheGlobals.playingMode = false;
5.     }

 

Looks like code wrapping System GC stuff which is totally pointless. I can't imagine any other way it would work, and I struggle to understand why it exists at all.

 

Not sure if this is an Incremental GC issue, but I am seeing a quite annoying set of Android crashes in Unity 2022.2.<any>, up to and including 2022.2.18f1

Example:

Code (CSharp):

1. ********** Crash dump: **********
2. Build fingerprint: 'Must use __system_property_read_callback() to read'
3. C:\Unity\2022.2.18f1\Editor\Data\PlaybackEngines\AndroidPlayer\NDK\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-readelf.exe: warning: 'Builds\tintin-1.60-1.60.0-v150000024.symbols\arm64-v8a\libunity.so': no valid dynamic table was found
4. #00 0x0000000000717f58 /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libunity.so (BuildId: 25ea76897427c160)
5.                                                                                                                            MemoryManager::VirtualAllocator::GetBlockInfoFromPointer(void const*)
6.                                                                                                                            ??:0:0
7. C:\Unity\2022.2.18f1\Editor\Data\PlaybackEngines\AndroidPlayer\NDK\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-readelf.exe: warning: 'Builds\tintin-1.60-1.60.0-v150000024.symbols\arm64-v8a\libunity.so': no valid dynamic table was found
8. #01 0x00000000007151b8 /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libunity.so (BuildId: 25ea76897427c160)
9.                                                                                                                            DualThreadAllocator<DynamicHeapAllocator>::Contains(void const*) const
10.                                                                                                                            ??:0:0
11. C:\Unity\2022.2.18f1\Editor\Data\PlaybackEngines\AndroidPlayer\NDK\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-readelf.exe: warning: 'Builds\tintin-1.60-1.60.0-v150000024.symbols\arm64-v8a\libunity.so': no valid dynamic table was found
12. #02 0x0000000000714fa8 /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libunity.so (BuildId: 25ea76897427c160)
13.                                                                                                                            DualThreadAllocator<DynamicHeapAllocator>::TryDeallocate(void*)
14.                                                                                                                            ??:0:0
15. C:\Unity\2022.2.18f1\Editor\Data\PlaybackEngines\AndroidPlayer\NDK\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-readelf.exe: warning: 'Builds\tintin-1.60-1.60.0-v150000024.symbols\arm64-v8a\libunity.so': no valid dynamic table was found
16. #03 0x0000000000717548 /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libunity.so (BuildId: 25ea76897427c160)
17.                                                                                                                            MemoryManager::Deallocate(void*, MemLabelId, char const*, int)
18.                                                                                                                            ??:0:0
19. #04 0x00000000021f9a40 /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libil2cpp.so (BuildId: 88e8f1251db9960b)
20.                                                                                                                             AnimationCurve_Internal_Destroy_m240B298D0A13EEC1652955C4BDCDBE9B7B2EE296
21.                                                                                                                             C:/Projects/tintin-bitbucket/tintin-unity/Library/Bee/artifacts/Android/il2cppOutput/cpp\UnityEngine.CoreModule.cpp:9683:2
22.                                                                                                                             AnimationCurve_Finalize_m803AC16166EE497C4DFA996B15692D91F4D04C3C
23.                                                                                                                             C:/Projects/tintin-bitbucket/tintin-unity/Library/Bee/artifacts/Android/il2cppOutput/cpp\UnityEngine.CoreModule.cpp:9728:4
24. #05 0x000000000110abcc /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libil2cpp.so (BuildId: 88e8f1251db9960b)
25.                                                                                                                             il2cpp::vm::Runtime::InvokeWithThrow(MethodInfo const*, void*, void**)
26.                                                                                                                             C:/Unity/2022.2.18f1/Editor/Data/il2cpp/libil2cpp/vm\Runtime.cpp:604:13
27. #06 0x000000000110ab18 /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libil2cpp.so (BuildId: 88e8f1251db9960b)
28.                                                                                                                             il2cpp::vm::Runtime::Invoke(MethodInfo const*, void*, void**, Il2CppException**)
29.                                                                                                                             C:/Unity/2022.2.18f1/Editor/Data/il2cpp/libil2cpp/vm\Runtime.cpp:590:20
30. #07 0x000000000110312c /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libil2cpp.so (BuildId: 88e8f1251db9960b)
31.                                                                                                                             il2cpp::gc::GarbageCollector::RunFinalizer(void*, void*)
32.                                                                                                                             C:/Unity/2022.2.18f1/Editor/Data/il2cpp/libil2cpp/gc\GarbageCollector.cpp:178:9
33. #08 0x00000000011918a4 /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libil2cpp.so (BuildId: 88e8f1251db9960b)
34.                                                                                                                             GC_invoke_finalizers
35.                                                                                                                             C:/Unity/2022.2.18f1/Editor/Data/il2cpp/external/bdwgc/extra/..\finalize.c:1315:9
36. #09 0x0000000001103074 /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libil2cpp.so (BuildId: 88e8f1251db9960b)
37.                                                                                                                             il2cpp::gc::GarbageCollector::InvokeFinalizers()
38.                                                                                                                             C:/Unity/2022.2.18f1/Editor/Data/il2cpp/libil2cpp/gc\BoehmGC.cpp:461:21
39.                                                                                                                             il2cpp::gc::FinalizerThread(void*)
40.                                                                                                                             C:/Unity/2022.2.18f1/Editor/Data/il2cpp/libil2cpp/gc\GarbageCollector.cpp:104:13
41. #10 0x00000000010f596c /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libil2cpp.so (BuildId: 88e8f1251db9960b)
42.                                                                                                                             il2cpp::os::Thread::RunWrapper(void*)
43.                                                                                                                             C:/Unity/2022.2.18f1/Editor/Data/il2cpp/libil2cpp/os\Thread.cpp:201:9
44. #11 0x0000000001181308 /data/app/~~KdB4CabvDgTZ8QkMGFr7kw==/com.fpg.tintin-WjfzEMh8FTgKO69IOwY1KA==/lib/arm64/libil2cpp.so (BuildId: 88e8f1251db9960b)
45.                                                                                                                             il2cpp::os::ThreadImpl::ThreadStartWrapper(void*)
46.                                                                                                                             C:/Unity/2022.2.18f1/Editor/Data/il2cpp/libil2cpp/os/Posix\ThreadImpl.cpp:123:9
47. #12 0x00000000000deb44 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264) (BuildId: bbbdeb7c87c74f1491f92c6e605095b0)
48. #13 0x000000000007b2fc /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+68) (BuildId: bbbdeb7c87c74f1491f92c6e605095b0)
49. Crash dump is completed

I don't think there should ever be a segfault in Garbage collection of objects instantiated by user code, so this is quite bewildering.

EDIT: Same behaviour without incremental GC, but since the crash is in a GC invocation, I'm still pretty sure it shouldn't even be possible to happen (yet it does).

One of these days where I really wish I could opt for a clean and lightweight Mono runtime on Mobile, because IL2CPP is nearly impossible to debug, and the engine itself crashing while it manages its own objects is really frustrating.