Runtime Crash in Build

General
1
  • A* version: 5.2.3
  • Unity version: 2022.3.22f

We have run into a issue with our usage of A*PathfindingProject Pro. At runtime in a release or debug build, we get a critical error (crash to desktop) with the stack-trace shown below. It happens roughly 20 minutes into a play session in which a flexible number of agents (0-100) traverse a RecastGrah and a PointGraph. No NavMeshCutting is used. We are usure what triggers the crash, typically no user action is performed immediately before it, sometimes a scan of the scene precedes the crash (which completes without errors). The Graphs are re-scanned relatively often however the crash does not seem to correlate with the scans.

Is there anything we can do to resolve this? Are there any known issues that may trigger such a crash?

========== OUTPUTTING STACK TRACE ==================

0x65B2A48E (UnityPlayer) profiler_begin<char const *,unsigned __int64>
0x65B471C6 (UnityPlayer) InitializeUnsafeUtilityTempMallocLabel
0x65B2A9F7 (UnityPlayer) profiler_begin<char const *,unsigned __int64>
0x65B31140 (UnityPlayer) GetTlsfAllocationSize
0x65B3361B (UnityPlayer) SuiteQueueAllocatorkUnitTestCategory::AllocCheckNotNull
0x6632BF34 (UnityPlayer) SuiteManagedTempMemScopekUnitTestCategory::ARewindPointWorks
0x658E9CE6 (UnityPlayer) UnsafeUtility::Malloc
0x658BDA61 (UnityPlayer) `anonymous namespace'::_ExceptionPtr_static<std::bad_alloc>::_Delete_this
0x6A16173B (lib_burst_generated) [C:\build\output\unity\unity\Runtime\Jobs\Managed\IJob.cs:58] Unity.Jobs.IJobExtensions.JobStruct`1<Pathfinding.Graphs.Navmesh.Jobs.JobBuildTileMeshFromVoxels>.Execute(ref Pathfinding.Graphs.Navmesh.Jobs.JobBuildTileMeshFromVoxels data, System.IntPtr additionalPtr, System.IntPtr bufferRangePatchData, ref Unity.Jobs.LowLevel.Unsafe.JobRanges ranges, int jobIndex) -> void_662504a657d93dcc1ffc44c5ac00b5a2 from UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null 
0x6A1592CA (lib_burst_generated) c7bd43dad8afab74e2910a0eea3eeaf4_x86_sse4
0x6A1B82B8 (lib_burst_generated) c7bd43dad8afab74e2910a0eea3eeaf4
0x65F6B18D (UnityPlayer) ExecuteJob
0x65F6B85D (UnityPlayer) ForwardJobToManaged
0x65F692A0 (UnityPlayer) ujob_execute_job
0x65F68693 (UnityPlayer) lane_guts
0x65F6AB3F (UnityPlayer) worker_thread_routine
0x662ABB66 (UnityPlayer) OldSetThreadName
0x75A3FCC9 (KERNEL32) BaseThreadInitThunk
0x77C080CE (ntdll) RtlGetAppContainerNamedObjectPath
0x77C0809E (ntdll) RtlGetAppContainerNamedObjectPath

========== END OF STACKTRACE ===========
2

Hi

Would it be possible for you to get a stack trace from a debug build?
This looks like it was from a release build.

3

This is an excerpt of the player log of a development build with full stack trace for errors/exceptions. Are there any infos I can provide that would help you out?

4

The excerpt doesn’t have any line numbers. And since that burst-compiled method references several thousands of lines of code, it’s hard to debug, I’m afraid.

You can try to do a build without burst. Alternatively enable the “Native Debug Mode” burst compilation option.

5

Thanks, I will try to reproduce the crash with both options and get back to you.

6

So far it appears the crash only appears when building for 32-bit architectures, since we do not actually need that, and 64-bit seems to work in all combinations (burst, mono, il2cpp) we see no need to further investigate the issue. If the issue reappears on 64-bit, we’ll post an update. Thanks for the help and quick response!

7

Hi

Good debugging.
Are you sure you didn’t just run out of memory? 32bit applications can only use 4GB of memory.

8

We assume that was the case, it would be the simplest explanation, however we never observed allocations approaching that limit. They may have occured momentarily however.