Leak Detected if AstarPath component disabled

  • A* version: [5.2.5] (the purchased version of A* Pathfinding Project Pro)
  • Unity version: [2022.3.53f1]
  • Burst version: [1.8.18]
  • Collections: [2.5.1]

Summary:

On Unity 2022.3.53f1 and the latest version of all dependencies, when the AstarPath component is disabled, a “Leak Detected: Persistent allocates 1 individual allocations.” message occurs after playing the scene more than once and persists on subsequent plays. This issue does not reoccur if the component is then enabled.

Callstack:

Found 1 leak(s) from callstack:
0x000002a5619c1a73 (Mono JIT Code) Unity.Collections.Memory/Unmanaged/Array:Resize (void*,long,long,Unity.Collections.AllocatorManager/AllocatorHandle,long,int) (at ./Library/PackageCache/com.unity.collections@2.5.1/Unity.Collections/Memory.cs:79)
0x000002a5619c1683 (Mono JIT Code) Unity.Collections.Memory/Unmanaged:Allocate (long,int,Unity.Collections.AllocatorManager/AllocatorHandle) (at ./Library/PackageCache/com.unity.collections@2.5.1/Unity.Collections/Memory.cs:20)
0x000002a564fb9fb3 (Mono JIT Code) Unity.Collections.LowLevel.Unsafe.UnsafeBitArray:Realloc (int) (at ./Library/PackageCache/com.unity.collections@2.5.1/Unity.Collections/UnsafeBitArray.cs:117)
0x000002a564fb9a7b (Mono JIT Code) Unity.Collections.LowLevel.Unsafe.UnsafeBitArray:SetCapacity (int) (at ./Library/PackageCache/com.unity.collections@2.5.1/Unity.Collections/UnsafeBitArray.cs:172)
0x000002a564fb975b (Mono JIT Code) Unity.Collections.LowLevel.Unsafe.UnsafeBitArray:Resize (int,Unity.Collections.NativeArrayOptions) (at ./Library/PackageCache/com.unity.collections@2.5.1/Unity.Collections/UnsafeBitArray.cs:147)
0x000002a564fb919b (Mono JIT Code) Unity.Collections.LowLevel.Unsafe.UnsafeBitArray:.ctor (int,Unity.Collections.AllocatorManager/AllocatorHandle,Unity.Collections.NativeArrayOptions) (at ./Library/PackageCache/com.unity.collections@2.5.1/Unity.Collections/UnsafeBitArray.cs:77)
0x000002a564fb8ce3 (Mono JIT Code) Pathfinding.Graphs.Navmesh.NavmeshUpdates/NavmeshUpdateSettings:.ctor (Pathfinding.NavmeshBase) (at ./Packages/com.arongranberg.astar/Navmesh/NavmeshUpdates.cs:82)
0x000002a564fb7f33 (Mono JIT Code) Pathfinding.NavmeshBase:.ctor () (at ./Packages/com.arongranberg.astar/Graphs/NavmeshBase.cs:1199)
0x000002a564fb1783 (Mono JIT Code) Pathfinding.RecastGraph:.ctor () (at ./Packages/com.arongranberg.astar/Graphs/RecastGraph.cs:1151)
0x000002a5ff8483c8 (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr)
0x00007ffec5584c4e (mono-2.0-bdwgc) mono_jit_runtime_invoke (at C:/build/output/Unity-Technologies/mono/mono/mini/mini-runtime.c:3445)
0x00007ffec54bd254 (mono-2.0-bdwgc) do_runtime_invoke (at C:/build/output/Unity-Technologies/mono/mono/metadata/object.c:3068)
0x00007ffec54bd7ef (mono-2.0-bdwgc) mono_runtime_invoke_checked (at C:/build/output/Unity-Technologies/mono/mono/metadata/object.c:3235)
0x00007ffec54c4a08 (mono-2.0-bdwgc) mono_runtime_try_invoke_array (at C:/build/output/Unity-Technologies/mono/mono/metadata/object.c:5751)
0x00007ffec53f4ee2 (mono-2.0-bdwgc) ves_icall_InternalInvoke (at C:/build/output/Unity-Technologies/mono/mono/metadata/icall.c:4041)
0x00007ffec541b0c1 (mono-2.0-bdwgc) ves_icall_InternalInvoke_raw (at C:/build/output/Unity-Technologies/mono/mono/metadata/icall-def.h:692)
0x000002a5ff49d8d2 (Mono JIT Code) (wrapper managed-to-native) System.Reflection.RuntimeConstructorInfo:InternalInvoke (System.Reflection.RuntimeConstructorInfo,object,object[],System.Exception&)
0x000002a5ff49d483 (Mono JIT Code) System.Reflection.RuntimeConstructorInfo:InternalInvoke (object,object[],bool)
0x000002a5229e62ab (Mono JIT Code) System.RuntimeType:CreateInstanceMono (bool,bool)

Intro:
I want to start on a positive note by saying this package is amazing! The amount of features, quality of documentation, performance etc is far greater than I had hoped for. Seriously good asset - thank you!

Detail:

I started seeing a leak after working on my game, and found it was due to how I am trying to use Astarpath. I don’t know if this will affect many other people but felt it worthwhile reporting the leak.
My game is procedural, and I want to control the pathing by first getting the scene content generated/loaded before enabling Astarpath and scanning the graphs etc.
Perhaps I am using this incorrectly and should just have Astarpath enabled constantly, regardless of having anything ready to scan/path? Even so, it shouldn’t be leaking.
The issue was initially tricky to recreate because the leak does not manifest on first Play but does on subsequent ones.

Steps I take to recreate:

1) Project Setup

  • A recent new install of Unity 2022.3.53f1
  • No previous version of A* Pathfinding Project installed, this is a new download of A* Pathfinding Project 5.2.5 via package manager.
  • Import of package is just base component, and does not include anything under ExampleScenes
  • Nothing in my scene except the main camera.
  • Add an empty gameobject
  • Add Astarpath component
  • Add a Recast Graph at default values

2) Recreating the issue

  • Hit play - no console warnings/errors
  • Stop playing
  • Disable Astarpath component
  • Hit play - no console warnings/errors
  • Stop playing
  • Hit play - Leak Detected
  • Repeat stop and play - Leak Detected every time

3) Resolving the issue

  • Stop playing
  • Enable Astarpath component
  • Hit play - no console warnings/errors
  • Repeat stop and play - No console warnings/errors anytime

Notes:

  • I can swap the Astarpath component for the gameobject itself in the steps above (enabling/disabling), and the results are the same.
  • “Cache startup” is left off as per default value. I have never used this feature.
  • Toggling “Scan on Awake” does not seem to make a difference to this issue. I will want it off because I eventually want to generate my terrains and colliders etc first before scanning.

I hope I’m just doing something silly. Let me know if you want more info. Thanks for any help.

Hi

Unity has had various bugs in their libraries, causing leaks where there shouldn’t be any.
I would recommend to first try upgrading burst, collections and if possible your unity version, to see if that resolves the issue.

Hi, I installed the latest version of Unity 6, upgraded my project, deleted all AstarPath, redownloaded it and re-imported it, created a brand new scene, followed my steps above, and the leak is still there.

These are the very latest versions:

  • A* version: [5.2.5] (the purchased version of A* Pathfinding Project Pro)
  • Unity version: [6000.0.31f1]
  • Burst version: [1.8.18]
  • Collections: [2.5.1]

Hi

I cannot replicate this :confused:
Not sure why.
@tealtxgr are you able to?

Yuppp, I got it on my end :+1:

Hello, I was wondering if this issue is due to be resolved at some point?
From time to time, using AStar I get memory leaks, and I don’t know if it is related to this or something different.
I’ve also had a couple of recent system crashes when my Unity scene has been open for a while - not saying it is caused by AStar but I would like to rule this out.

Looks like this one got lost in the weeds, sorry about that :slight_smile: I’ll let Aron know about this one again

Like full Windows crashing? Is there anything about the crash/scenarios that may shed any light to why it’s happening? I also have doubts this would be an Astar thing (more likely an OS or Unity thing) but I’m willing to hear anything out :slight_smile: In that line of thinking, I’d recommend opening a Unity ticket for this if you can. They’d have better clarity on a system crash than we.

Yeah don’t worry about the windows crash, I will diagnose more once this leak has been fixed as its likely unconnected.

The leak is concerning though, and hints at some potential instability. If the Astarpath component is disabled, why is it even executing to cause a leak?

I can’t say much here, as I’m not familiar with the code on that level to say. We’ll have to see what Aron says about it :+1:

1 Like

Hi

Are you able to replicate this in the latest update? (5.3.3).
There have been some recent fixes for memory leaks.

Hi Aron, unfortunately this issue is still reproducible in 5.3.3

I have run it with with Jobs → Burst → Native Debug Mode Compilation to get the stack which I’ve posted below. I’ve noticed some line numbers have changed but it still seems to be triggered by the NavmeshUpdateSettings consructor:

Found 1 leak(s) from callstack:
0x0000015071379203 (Mono JIT Code) Unity.Collections.Memory/Unmanaged/Array:Resize (void*,long,long,Unity.Collections.AllocatorManager/AllocatorHandle,long,int) (at ./Library/PackageCache/com.unity.collections/Unity.Collections/Memory.cs:79)
0x0000015071378aa3 (Mono JIT Code) Unity.Collections.Memory/Unmanaged:Allocate (long,int,Unity.Collections.AllocatorManager/AllocatorHandle) (at ./Library/PackageCache/com.unity.collections/Unity.Collections/Memory.cs:20)
0x00000150968c7cd3 (Mono JIT Code) Unity.Collections.LowLevel.Unsafe.UnsafeBitArray:Realloc (int) (at ./Library/PackageCache/com.unity.collections/Unity.Collections/UnsafeBitArray.cs:117)
0x00000150968c776b (Mono JIT Code) Unity.Collections.LowLevel.Unsafe.UnsafeBitArray:SetCapacity (int) (at ./Library/PackageCache/com.unity.collections/Unity.Collections/UnsafeBitArray.cs:172)
0x00000150968c740b (Mono JIT Code) Unity.Collections.LowLevel.Unsafe.UnsafeBitArray:Resize (int,Unity.Collections.NativeArrayOptions) (at ./Library/PackageCache/com.unity.collections/Unity.Collections/UnsafeBitArray.cs:147)
0x00000150968c6dfb (Mono JIT Code) Unity.Collections.LowLevel.Unsafe.UnsafeBitArray:.ctor (int,Unity.Collections.AllocatorManager/AllocatorHandle,Unity.Collections.NativeArrayOptions) (at ./Library/PackageCache/com.unity.collections/Unity.Collections/UnsafeBitArray.cs:77)
0x00000150968c6903 (Mono JIT Code) Pathfinding.Graphs.Navmesh.NavmeshUpdates/NavmeshUpdateSettings:.ctor (Pathfinding.NavmeshBase) (at ./Packages/com.arongranberg.astar/Navmesh/NavmeshUpdates.cs:82)
0x00000150968c5ad3 (Mono JIT Code) Pathfinding.NavmeshBase:.ctor () (at ./Packages/com.arongranberg.astar/Graphs/NavmeshBase.cs:1211)
0x00000150968aeaa3 (Mono JIT Code) Pathfinding.RecastGraph:.ctor () (at ./Packages/com.arongranberg.astar/Graphs/RecastGraph.cs:1155)
0x0000014f35f611f8 (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr)
0x00007ffa39e369ce (mono-2.0-bdwgc) mono_jit_runtime_invoke (at C:/build/output/Unity-Technologies/mono/mono/mini/mini-runtime.c:3445)
0x00007ffa39d78474 (mono-2.0-bdwgc) do_runtime_invoke (at C:/build/output/Unity-Technologies/mono/mono/metadata/object.c:3068)
0x00007ffa39d788f1 (mono-2.0-bdwgc) mono_runtime_invoke_checked (at C:/build/output/Unity-Technologies/mono/mono/metadata/object.c:3235)
0x00007ffa39d7f3ca (mono-2.0-bdwgc) mono_runtime_try_invoke_array (at C:/build/output/Unity-Technologies/mono/mono/metadata/object.c:5751)
0x00007ffa39cb1a01 (mono-2.0-bdwgc) ves_icall_InternalInvoke (at C:/build/output/Unity-Technologies/mono/mono/metadata/icall.c:4038)
0x00007ffa39cd7cb1 (mono-2.0-bdwgc) ves_icall_InternalInvoke_raw (at C:/build/output/Unity-Technologies/mono/mono/metadata/icall-def.h:692)
0x00000150c21248d2 (Mono JIT Code) (wrapper managed-to-native) System.Reflection.RuntimeConstructorInfo:InternalInvoke (System.Reflection.RuntimeConstructorInfo,object,object[],System.Exception&)
0x00000150c2124483 (Mono JIT Code) System.Reflection.RuntimeConstructorInfo:InternalInvoke (object,object[],bool)
0x00000150d3c9769b (Mono JIT Code) System.RuntimeType:CreateInstanceMono (bool,bool)

Don’t know if it is related, but on line 82 (in OnEnable) of AstarPathEditor, there is a check of script.data.graphs.Length:

if ((!Application.isPlaying && (script.data.graphs == null || script.data.graphs.Length == 0)) || script.data.graphs == null) {
	DeserializeGraphs();
}

As my graphs.Length is zero, it does begin DeserializeGraphs.
But it doesn’t seem the length would be correct at that point anyway since for

public NavGraph[] graphs = new NavGraph[0];

the comment is:

		/// This will be filled only after deserialization has completed.
		/// May contain null entries if graph have been removed.

Anyway, I’m happy to try things / conduct more tests. Let me know if I can help.

Just wanted to say, in case it helps reproduce/narrow down the issue, that I’ve discovered another way to quickly recreate the leak using a prefab.

Similar process/setup to my original steps in my first post here, but before step 2 (enabling/disabling the Astarpath component), just drag the Astar gameobject into the project as a prefab.
Open/view the prefab.
Close the prefab.
Run the scene, get the leak straight away.

It seems the leak manifests itself following a “non-standard” initialisation attempt of the component (via a prefab view, or disabling in a scene).

1 Like

Thanks! I managed to replicate it, and I’ll include a fix in the next update.

2 Likes