Is there a performance or memory leak issue with this version?
Since upgrading to fix the vulnerability issue, we are getting massive incoming emails regarding crashes and lags with the game.
Updated editor from 2022.3.57 to 3.62.
We have upgraded from 2022.3.62f1 to 2022.3.67f2 and started to get massive tickets about lags and glitches from the game. It’s highly possible that they comes from the Unity update.
We also got a lot of crash on Android after upgrade the engine version from Unity 2022.3.62f1 to 2022.3.62f2
According to Firebase Crashlytics, most of the crash happen when device have <100mb of RAM
PS: I just release a build with 2022.3.62f1 and use the 1.3.0 patcher on the app .ABB file, let’s see if it will fix the crash
Here some of our crash stacktrace:
null pointer dereference: SIGSEGV 0x0000000000000000
#00 pc 0xd3f1c libc.so (BuildId: 899237b27ce70ad3ff85d806309243c0)
#01 pc 0xeab968 libunity.so (jni::NewObject(_jclass*, _jmethodID*, ...)) (BuildId: 02f260ba99305963)
#02 pc 0x5350064 libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#03 pc 0x5350054 libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#04 pc 0x534d1d4 libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#05 pc 0x5336b54 libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#06 pc 0x5e9ed8 libart.so (BuildId: 80d2ab18f9d259d8e546c1e6bae752b1)
#07 pc 0x5e9ed8 libart.so (BuildId: 80d2ab18f9d259d8e546c1e6bae752b1)
#08 pc 0x534d1ac libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#09 pc 0x6ef7ec libunity.so (PlayerPrefs::GetInt(core::basic_string<char, core::StringStorageDefault<char> > const&, int)) (BuildId: 02f260ba99305963)
#10 pc 0x414a00 libunity.so (Marshalling::StringMarshaller::EnsureMarshalled()) (BuildId: 02f260ba99305963)
#11 pc 0x3f80f8 libunity.so (PlayerPrefs_CUSTOM_GetInt(ScriptingBackendNativeStringPtrOpaque*, int)) (BuildId: 02f260ba99305963)
#12 pc 0x534fffd libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#13 pc 0x26854a4 libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#14 pc 0x5336b54 libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#15 pc 0x5337eac libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#16 pc 0x53896ac libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#17 pc 0x268ce30 libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#18 pc 0x534d1d4 libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
null pointer dereference: SIGSEGV 0x0000000000000000
#00 pc 0xc3674 libc.so (BuildId: cd953571180b7f5f8ae5570dad29595f)
#01 pc 0xeaa788 libunity.so (jni::CheckForExceptionError(_JNIEnv*)) (BuildId: 02f260ba99305963)
#02 pc 0x64ba5c libunity.so (scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool)) (BuildId: 02f260ba99305963)
#03 pc 0x65ba78 libunity.so (ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)) (BuildId: 02f260ba99305963)
#04 pc 0x662278 libunity.so (Coroutine::Run(bool*)) (BuildId: 02f260ba99305963)
#05 pc 0x12b8ddc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#06 pc 0x130a3a4 libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#07 pc 0x6625ac libunity.so (Coroutine::InvokeMoveNext(ScriptingExceptionPtr*)) (BuildId: 02f260ba99305963)
#08 pc 0x65ba78 libunity.so (ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)) (BuildId: 02f260ba99305963)
#09 pc 0x130a3a4 libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#10 pc 0x664544 libunity.so (MonoBehaviour::CallUpdateMethod(int)) (BuildId: 02f260ba99305963)
#11 pc 0x6621a4 libunity.so (Coroutine::Run(bool*)) (BuildId: 02f260ba99305963)
#12 pc 0x49aaf8 libunity.so (DelayedCallManager::Update(int)) (BuildId: 02f260ba99305963)
#13 pc 0x6620f0 libunity.so (Coroutine::Coroutine()) (BuildId: 02f260ba99305963)
#14 pc 0x561100 libunity.so (ExecutePlayerLoop(NativePlayerLoopSystem*)) (BuildId: 02f260ba99305963)
#15 pc 0x22c6288 libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#16 pc 0x533336c libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#17 pc 0x2306a60 libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#18 pc 0x55adffc libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#19 pc 0x22c9c3c libil2cpp.so (BuildId: df8c8320a2a5009ee981c87102594522c568d48b)
#20 pc 0x561140 libunity.so (ExecutePlayerLoop(NativePlayerLoopSystem*)) (BuildId: 02f260ba99305963)
#21 pc 0x70bbf8 libunity.so (Scripting::UnityEngine::Rendering::OnDemandRenderingProxy::GetRenderFrameInterval(int*, ScriptingExceptionPtr*)) (BuildId: 02f260ba99305963)
#22 pc 0x130dffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#23 pc 0x130dffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#24 pc 0x63eec libc.so (BuildId: cd953571180b7f5f8ae5570dad29595f)
#25 pc 0x65ba78 libunity.so (ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)) (BuildId: 02f260ba99305963)
#26 pc 0x130a3a4 libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#27 pc 0x5613ec libunity.so (PlayerLoop()) (BuildId: 02f260ba99305963)
#28 pc 0x130dffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#29 pc 0x130dffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#30 pc 0x12feffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#31 pc 0x130dffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#32 pc 0x130dffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#33 pc 0x6d3020 libunity.so (AndroidAssetPacks::AssetPackManager::UpdateCoreAssetPacksStatus()) (BuildId: 02f260ba99305963)
#34 pc 0x130dffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#35 pc 0x130dffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#36 pc 0x130dffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#37 pc 0x6e04f0 libunity.so (UnityPlayerLoop()) (BuildId: 02f260ba99305963)
#38 pc 0x6e04c8 libunity.so (UnityPlayerLoop()) (BuildId: 02f260ba99305963)
#39 pc 0x130dffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#40 pc 0x1286ffc libunity.so (__CortexA53843419_120F000) (BuildId: 02f260ba99305963)
#41 pc 0x6f5cac libunity.so (nativeRender(_JNIEnv*, _jobject*)) (BuildId: 02f260ba99305963)
#42 pc 0x71d9d570
#43 pc 0x732ee093d4
#44 pc 0x70ee55ec
#45 pc 0x7167248c
#46 pc 0x71676928
#47 pc 0x7167639c
#48 pc 0xc0ee1c libart.so (BuildId: eb4ec0f1d1c7267591d83fa87cb36390)
#49 pc 0x732ee09f24
#50 pc 0xfe950 libc.so (BuildId: cd953571180b7f5f8ae5570dad29595f)
#51 pc 0xc0cffc libart.so (BuildId: eb4ec0f1d1c7267591d83fa87cb36390)
#52 pc 0x317194 libart.so (BuildId: eb4ec0f1d1c7267591d83fa87cb36390)
#53 pc 0x302838 libart.so (BuildId: eb4ec0f1d1c7267591d83fa87cb36390)
#54 pc 0x4c8298 libart.so (BuildId: eb4ec0f1d1c7267591d83fa87cb36390)
#55 pc 0xc295c libc.so (BuildId: cd953571180b7f5f8ae5570dad29595f)
#56 pc 0x105ffc libc.so (BuildId: cd953571180b7f5f8ae5570dad29595f)
#57 pc 0xeb720 libc.so (BuildId: cd953571180b7f5f8ae5570dad29595f)
#58 pc 0x105ffc libc.so (BuildId: cd953571180b7f5f8ae5570dad29595f)
#59 pc 0x7e2d0 libc.so (BuildId: cd953571180b7f5f8ae5570dad29595f)
#60 pc 0xeb64c libc.so (BuildId: cd953571180b7f5f8ae5570dad29595f)
#61 pc 0x13a4fc ld-android.so (BuildId: b8565d4b0a7cb4a1cfa943038112e4c2)
#62 pc 0x13a7fc ld-android.so (BuildId: b8565d4b0a7cb4a1cfa943038112e4c2)
#63 pc 0x4c7ef0 libart.so (BuildId: eb4ec0f1d1c7267591d83fa87cb36390)
I was not able to reproduce the issue, but due to all the complaints received, the build was rebuilt with 3.57 and patched with the 1.30 patcher and all the complaints disappeared.
I am confident to say there is a problem with 3.62f2. However, i cant reproduce or noticed any crash logs from Google Play or Crashytics.
I did find a point in time where there were 25% users crashing in crashlytics and majority of the stack trace shows this before the crash.
0x8a0e5e: TilemapRendererJobs::SharedTileSpriteRenderData::~SharedTileSpriteRenderData()
??:0
0xd1c5ee: ParticleSystemTrailGeometryJob::RenderJobCommon(ParticleSystemTrailGeometryJob&, void*, void*, unsigned int, unsigned int, unsigned int)
Hey there everyone!
Reading through this thread it looks like there are different crashes being talked about.
The one “hloc002” and “mrm831” are experiencing appear to be different from one another, or rather the causes appear to be different.
I can’t really say more as I don’t have enough context on the crashes, as it would greatly help if the Stack Traces were symbolized or at least how the crash is approached. What exactly are the users doing to get to the crash. I’ve conversed with our developers and there are a few reports that sound similar, but there’s no way to be sure without comparing the Stack Traces.
If you guys can, please reproduce the issue on a local minimal project if possible and if the issue happens in Players and not the Editors, make sure that your built Players have “Development Build” turned on in the Build Settings before building and testing. That way the Stack Traces would be more informative on what’s going on.
Additionally, with no access to a repro project from our side, we can’t manually narrow down where the issue is happening and if it is indeed a bug from our side it would be harder to verify if a fix indeed worked or not, which in turn becomes a guessing game.
So if possible, please use the Unity Bug Reporting tool and send over all of the mentioned information here plus:
- Repro project ← minimal or the full project where the issue is happening
- Repro steps - What are we supposed to do to get to the point of reproduction (in this case the crash)
- Logcat log - If it’s an Android Crash (Prefferrably symbolized with “Development Build” to make sure we are getting the same crash if we can reproduce it"
- Stack Trace from the Player.log if it’s a crash in Standalone Players
An example of the repro steps:
- Build and Run Project with “SceneName” Scene
- Select “This” Menu Button
- Do “This” Action
- Move in the Player “Here”
- Crash
Unfortunately, the crash can not be reproduced locally. But we’ve received videos showing the issue. The game becomes lagging like 1 FPS, and then eventually crashes.
These are the best traces I can extract, not sure if it will help.
0x0000000000000000: ??
??:0
0x8a0e5e: TilemapRendererJobs::SharedTileSpriteRenderData::~SharedTileSpriteRenderData()
??:0
0xd1c5ee: ParticleSystemTrailGeometryJob::RenderJobCommon(ParticleSystemTrailGeometryJob&, void*, void*, unsigned int, unsigned int, unsigned int)
??:0
0x1ca263: ??
??:0
0x2cceff: ??
??:0
0x2ccfcb: ??
??:0
0x26584d: ??
??:0
0x2e3d63: ??
??:0
0xd1540e: void UpdateOrbitalAndRadialTpl<(ParticleSystemCurveEvalMode)4, (ParticleSystemCurveEvalMode)4, (ParticleSystemCurveEvalMode)2>(MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, ParticleSystemParticles&, unsigned long, unsigned long, math::float3x3 const&, math::affineX const&, float vector[4] const&)
??:0
0x1cbeab: ??
??:0
0x105b93: ??
??:0
0xd15182: void UpdateOrbitalAndRadialTpl<(ParticleSystemCurveEvalMode)4, (ParticleSystemCurveEvalMode)4, (ParticleSystemCurveEvalMode)2>(MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, ParticleSystemParticles&, unsigned long, unsigned long, math::float3x3 const&, math::affineX const&, float vector[4] const&)
??:0
0x105b93: ??
??:0
0x1c9803: ??
??:0
0x105b93: ??
??:0
0x1e6e7b: ??
??:0
0x105b93: ??
??:0
0x512a8f: GraphicsCaps::GraphicsCaps()
??:0
0x105b93: ??
??:0
0x51098b: std::__ndk1::vector<core::basic_string<char, core::StringStorageDefault<char> >, stl_allocator<core::basic_string<char, core::StringStorageDefault<char> >, (MemLabelIdentifier)1, 16> >::vector<std::__ndk1::__wrap_iter<core::basic_string<char, core::StringStorageDefault<char> >*> >(std::__ndk1::__wrap_iter<core::basic_string<char, core::StringStorageDefault<char> >*>, std::__ndk1::__wrap_iter<core::basic_string<char, core::StringStorageDefault<char> >*>, stl_allocator<core::basic_string<char, core::StringStorageDefault<char> >, (MemLabelIdentifier)1, 16> const&, std::__ndk1::enable_if<(__is_cpp17_forward_iterator<std::__ndk1::__wrap_iter<core::basic_string<char, core::StringStorageDefault<char> >*> >::value) && (is_constructible<core::basic_string<char, core::StringStorageDefault<char> >, std::__ndk1::iterator_traits<std::__ndk1::__wrap_iter<core::basic_string<char, core::StringStorageDefault<char> >*> >::reference>::value), void>::type*)
??:0
0x50e5dd: unsigned int std::__ndk1::__sort3<std::__ndk1::__less<core::basic_string<char, core::StringStorageDefault<char> >, core::basic_string<char, core::StringStorageDefault<char> > >&, core::basic_string<char, core::StringStorageDefault<char> >*>(core::basic_string<char, core::StringStorageDefault<char> >*, core::basic_string<char, core::StringStorageDefault<char> >*, core::basic_string<char, core::StringStorageDefault<char> >*, std::__ndk1::__less<core::basic_string<char, core::StringStorageDefault<char> >, core::basic_string<char, core::StringStorageDefault<char> > >&)
??:0
0xd0097e: void UpdateOrbitalAndRadialTpl<(ParticleSystemCurveEvalMode)1, (ParticleSystemCurveEvalMode)0, (ParticleSystemCurveEvalMode)1>(MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, ParticleSystemParticles&, unsigned long, unsigned long, math::float3x3 const&, math::affineX const&, float vector[4] const&)
??:0
0x0000000000fffff0: physx::Gu::pcmContactConvexConvex(physx::Gu::GeometryUnion const&, physx::Gu::GeometryUnion const&, physx::PxTransform const&, physx::PxTransform const&, physx::Gu::NarrowPhaseParams const&, physx::Gu::Cache&, physx::Gu::ContactBuffer&, physx::Cm::RenderOutput*)
??:0
0x1cb1a2: ??
??:0
0xd1c5ee: ParticleSystemTrailGeometryJob::RenderJobCommon(ParticleSystemTrailGeometryJob&, void*, void*, unsigned int, unsigned int, unsigned int)
??:0
0x1ca257: ??
??:0
0x267215: ??
??:0
0x2cceff: ??
??:0
0x2ccfcb: ??
??:0
0x26584d: ??
??:0
0x2e3d63: ??
??:0
0xd1540e: void UpdateOrbitalAndRadialTpl<(ParticleSystemCurveEvalMode)4, (ParticleSystemCurveEvalMode)4, (ParticleSystemCurveEvalMode)2>(MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, ParticleSystemParticles&, unsigned long, unsigned long, math::float3x3 const&, math::affineX const&, float vector[4] const&)
??:0
0x1cbeab: ??
??:0
0x105b93: ??
??:0
0xd15182: void UpdateOrbitalAndRadialTpl<(ParticleSystemCurveEvalMode)4, (ParticleSystemCurveEvalMode)4, (ParticleSystemCurveEvalMode)2>(MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, ParticleSystemParticles&, unsigned long, unsigned long, math::float3x3 const&, math::affineX const&, float vector[4] const&)
??:0
0x105b93: ??
??:0
0x1c9803: ??
??:0
0x105b93: ??
??:0
0x1e6e7b: ??
??:0
0x105b93: ??
??:0
0x512a8f: GraphicsCaps::GraphicsCaps()
??:0
0x105b93: ??
??:0
0x51098b: std::__ndk1::vector<core::basic_string<char, core::StringStorageDefault<char> >, stl_allocator<core::basic_string<char, core::StringStorageDefault<char> >, (MemLabelIdentifier)1, 16> >::vector<std::__ndk1::__wrap_iter<core::basic_string<char, core::StringStorageDefault<char> >*> >(std::__ndk1::__wrap_iter<core::basic_string<char, core::StringStorageDefault<char> >*>, std::__ndk1::__wrap_iter<core::basic_string<char, core::StringStorageDefault<char> >*>, stl_allocator<core::basic_string<char, core::StringStorageDefault<char> >, (MemLabelIdentifier)1, 16> const&, std::__ndk1::enable_if<(__is_cpp17_forward_iterator<std::__ndk1::__wrap_iter<core::basic_string<char, core::StringStorageDefault<char> >*> >::value) && (is_constructible<core::basic_string<char, core::StringStorageDefault<char> >, std::__ndk1::iterator_traits<std::__ndk1::__wrap_iter<core::basic_string<char, core::StringStorageDefault<char> >*> >::reference>::value), void>::type*)
??:0
0x50e5dd: unsigned int std::__ndk1::__sort3<std::__ndk1::__less<core::basic_string<char, core::StringStorageDefault<char> >, core::basic_string<char, core::StringStorageDefault<char> > >&, core::basic_string<char, core::StringStorageDefault<char> >*>(core::basic_string<char, core::StringStorageDefault<char> >*, core::basic_string<char, core::StringStorageDefault<char> >*, core::basic_string<char, core::StringStorageDefault<char> >*, std::__ndk1::__less<core::basic_string<char, core::StringStorageDefault<char> >, core::basic_string<char, core::StringStorageDefault<char> > >&)
??:0
0xd0097e: void UpdateOrbitalAndRadialTpl<(ParticleSystemCurveEvalMode)1, (ParticleSystemCurveEvalMode)0, (ParticleSystemCurveEvalMode)1>(MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, MinMaxCurve const&, ParticleSystemParticles&, unsigned long, unsigned long, math::float3x3 const&, math::affineX const&, float vector[4] const&)
??:0
Same problem after updating Unity from 2022.3.58f1 to 2022.3.62f2
Hello, it was the same for me, after upgrading my project from Unity 2021.3.45f1 to 2022.3.62f2, many Android users started reporting lags and crashes.
Using Memory Profiler, I found that while the game normally used around 600 MB to 1.2 GB of RAM, it now grew to 4–6 GB+, depending on session length. Memory usage kept increasing the longer the game ran, until it crashed due to the device running out of memory.
It appears there’s some kind of memory leak, any MonoBehaviour objects that are spawned and then destroyed are not being freed from memory. The more objects are spawned, the more memory usage increases. At first, I thought something was wrong with Addressables and my own code, even though I didn’t change anything after upgrading Unity. However, even pooled objects, which are simply enabled and disabled repeatedly, still caused memory usage to increase.
The profiler showed the leaked memory as “Unrooted”, meaning it just didn’t know itself what was taking the memory.
I tried downgrading to 2022.3.62f1, but the memory leak persisted. Then I noticed I also had 2022.3.55f1 installed and decided to test it, and yes, it completely fixed the problem. Memory usage went back to normal (around 600 MB–1.2 GB), and there was no more unexplained ‘Unrooted’ memory growth taking up several gigabytes
I’ve talked with our developers and it might be this issue here:
It was fixed of course, but the version is only available for xLTS users.
Only way going forward right now is to downgrade the project to a working version where the crashes did not occur and then using the patcher on the apk/aab files.
Had it been caused by the CVE fix, then of course the version with the fix would have been made available to everyone as 2022.3.62f3 or something similar.
As you’ve mentioned, after downgrading to 62f1 from f2, shows that the bug is not caused by the CVE fix.
The same recommendation goes as above mentioned, please downgrade to a working version, e.g: 2022.3.55f1 (That you’ve verified as working) and use the patcher on the APK/AAB files.
I don’t have enough information to go on, to see if we have a report for this issue as I would need additional information to narrow it down, like affected device models or specific hardware e.g: Samsung S24, Adreno GPUs, and etc…
I see there’s a 5 version jump between the two, there is that odd chance that the CVE fix might have caused it.
Then again it could be a regression in between those two versions, without additional information it’s impossible to even begin investigating as lags and glitches can be caused by a thousand different things.
In this case I would recommend submitting a bug report via the Bug Reporter tool and please make sure to do the following:
- Attach a reproduction project where the issue could be manually tested
- Write down the necessary reproduction steps so that we would know where to observe the issue, starting from which Scene to build and how to get to the point of the bug
- List any known devices that are affected if it’s a Mobile issue
Additional information can be found here:
Yes, the problem turned out not to be related to the CVE, but I believe it’s the actual issue the author of this topic mentioned. Since he mentioned a memory leak and a massive amount of emails about crashes and lags, he probably assumed it was caused by the CVE fix version, just like I did before.
It was the same for me — all of my testers reported lags and crashes. It happens on all devices, regardless of model, the game eventually starts to lag and crash once the device runs out of memory, this can happen sooner or later depending on a device’s RAM. There’s a memory leak in versions 2022.3.62f1 and 2022.3.62f2, and possibly in some earlier ones as well.
I’ll try to test it in an empty project and submit a report if that’s needed.
The memory leak is connected to 2D physics. I created a new project, placed a bunch of objects with 2D Box Colliders and Dynamic Rigidbodies on a static collider, and used a script to repeatedly toggle their colliders on and off — that already caused a memory leak, even in the Editor.
I also built the project for Windows and Android just to confirm — and yeah, it’s the same there too.
I’ve submitted a bug report with that project attached.
I agree that the leak is related to 2D physics. I use a lot of 2D rigid body and 2D box collider objects, pooling them so they repeatedly disabled and enabled. Overtime the android device getting hot and crash (Samsung Galaxy S22+, a flagship device not a low end one). The only log available is that the app is killed by android lmkd ( Android Low Memory Killer Daemon) after it surpassed 3 Gigabytes of allocated memory. No any other log available. The problem happens when built with Unity 2022.3.62f2 or 62f1. If I build the app with Unity 2022.3.50f1 the game runs overwhelmingly smooth.
Yeah your report would really help us out as otherwise the only option would be constant back and forth communication.
Mainly why we ask everyone encountering bugs, to send us a project and the steps needed to reproduce the issue locally, is so that we could manually test:
- All Streams that are currently supported
- Try to see if maybe some option in Build Settings is the cause (If Player bug)
- Try to see maybe specific assets are causing it
- … more different things and all are dependent on the bug encountered…
So if you send us a project where the issue reproduces that’ll really help a lot.
Edit: Found the bug report and once it’s sent over for the developers to fix, I’ll update here with the Issue Tracker link
I found out that this memory leak bug was already reported several months ago and, as stated in the patch notes for 2022.3.64f1, it was fixed there.
However the problem is that this version and newer ones are available only for Enterprise users, while the last regular version of Unity 2022 LTS still has this severe memory leak bug since May.
The newly released version with the security issue fixed also still has this bug.
So.. my question is — are we potentially going to get a version of Unity 2022 that includes both the fix for this bug and the security patch? As I understand, support for Unity 2022 LTS is officially over, since we haven’t received a new version with the fix since May, the bug was already known, but the fix was released for Enterprise only.
Due to the recent security risks and the new Android 15 16 KB memory support requirements, many developers have moved from older Unity versions to the latest 2022 LTS and are now facing this severe bug. This effectively makes the last publicly available recommended version of Unity 2022 LTS unusable for all 2D games with physics across all platforms
Any reason why you are not using Unity 6 LTS?
Major version update = extremely high risk for existing projects.
Just look at the problems exploded from 5 version of same version updates.
Everytime we have to update Unity, we get heart attacks.
I’d like to add that this was originally discussed here on May 31st and as requested, I received a report on June 2nd and fixes for 2022.3.64f1, 6000.0.52f1, 6000.1.8f1, 6000.2.0b6 and 6000.3.0a1 landed a few days later.
I’m not in control of the patches for 2022 and wasn’t aware that the fix wasn’t generally available but I can certainly ask internally about it for you right now.