Dynamic Navmesh Crash during DemandLazyDataGathering when sequences finish (FMRSWRecursiveAccessDetector)

Development Platform & Builds
, ,
1

Ever since we moved to 5.7 we are experiencing a new type of crash during cinematics when a blueprint with static meshes that *invalidates* dynamic navmesh is unloaded while its trying to generate the navmesh on the task thread.

This is usually happening at the end of a cinematic track and currently we keep having to find objects that are in cinematics that are invalidating navmesh but its kind of weird that this kind of thing would suddenly start crashing once we moved to 5.7.

Is this a known issue and/or is there something we can integrate from 5.8 or ue5-main to fix this?

Thanks,

Bane

[Attachment Removed]

2

I just did some more debugging the package and i’m also seeing this trigger:

Ensure condition failed: UE::Private::FMTAccessDetectorOptions::bSuppressCheckFailure [File:T:\HEAT\Engine\Source\Runtime\Core\Public\Misc\MTAccessDetector.h] [Line: 624]

Either a race detected (1 reader(s) on another thread(s) while acquiring write access on the current thread) or the access detector was trivially relocated:

Current thread 533704 callstack:

0x00007ff7daf7c731 TankHead.exe!FMRSWRecursiveAccessDetector::GetCurrentThreadCallstack() [T:\HEAT\Engine\Source\Runtime\Core\Public\Misc\MTAccessDetector.h:413]

0x00007ff7eb3c1984 TankHead.exe!`FMRSWRecursiveAccessDetector::AcquireWriteAccess’::`8’::<lambda_2>::operator()() [T:\HEAT\Engine\Source\Runtime\Core\Public\Misc\MTAccessDetector.h:624]

0x00007ff7daf69191 TankHead.exe!FMRSWRecursiveAccessDetector::AcquireWriteAccess() [T:\HEAT\Engine\Source\Runtime\Core\Public\Misc\MTAccessDetector.h:628]

0x00007ff7daf7eb65 TankHead.exe!TDelegateAccessHandlerBase<FNotThreadSafeDelegateMode>::GetWriteAccessScope() [T:\HEAT\Engine\Source\Runtime\Core\Public\Delegates\DelegateAccessHandler.h:169]

0x00007ff7db289370 TankHead.exe!TDelegateBase<FNotThreadSafeDelegateMode>::operator=() [T:\HEAT\Engine\Source\Runtime\Core\Public\Delegates\DelegateBase.h:285]

0x00007ff7e08a8667 TankHead.exe!UNavigationObjectRepository::RegisterNavRelevantObjectInternal() [T:\HEAT\Engine\Source\Runtime\NavigationSystem\Private\NavigationObjectRepository.cpp:120]

0x00007ff7e08bc21d TankHead.exe!UNavigationSystemV1::UpdateNavRelevantObjectInNavOctreeStatic() [T:\HEAT\Engine\Source\Runtime\NavigationSystem\Private\NavigationSystem.cpp:3709]

0x00007ff7e08b90bc TankHead.exe!UNavigationSystemV1::UpdateComponentInNavOctree() [T:\HEAT\Engine\Source\Runtime\NavigationSystem\Private\NavigationSystem.cpp:3804]

0x00007ff7e0e9e843 TankHead.exe!FNavigationSystem::UpdateComponentData() [T:\HEAT\Engine\Source\Runtime\Engine\Private\AI\NavigationSystemBase.cpp:272]

[2026.03.23-23.11.26:094][985]LogOutputDevice: Error: Ensure condition failed: UE::Private::FMTAccessDetectorOptions::bSuppressCheckFailure [File:T:\HEAT\Engine\Source\Runtime\Core\Public\Misc\MTAccessDetector.h] [Line: 624]

Either a race detected (1 reader(s) on another thread(s) while acquiring write access on the current thread) or the access detector was trivially relocated:

Current thread 533704 callstack:

0x00007ff7daf7c731 TankHead.exe!FMRSWRecursiveAccessDetector::GetCurrentThreadCallstack() [T:\HEAT\Engine\Source\Runtime\Core\Public\Misc\MTAccessDetector.h:413]

0x00007ff7eb3c1984 TankHead.exe!`FMRSWRecursiveAccessDetector::AcquireWriteAccess’::`8’::<lambda_2>::operator()() [T:\HEAT\Engine\Source\Runtime\Core\Public\Misc\MTAccessDetector.h:624]

0x00007ff7daf69191 TankHead.exe!FMRSWRecursiveAccessDetector::AcquireWriteAccess() [T:\HEAT\Engine\Source\Runtime\Core\Public\Misc\MTAccessDetector.h:628]

0x00007ff7daf7eb65 TankHead.exe!TDelegateAccessHandlerBase<FNotThreadSafeDelegateMode>::GetWriteAccessScope() [T:\HEAT\Engine\Source\Runtime\Core\Public\Delegates\DelegateAccessHandler.h:169]

0x00007ff7db289370 TankHead.exe!TDelegateBase<FNotThreadSafeDelegateMode>::operator=() [T:\HEAT\Engine\Source\Runtime\Core\Public\Delegates\DelegateBase.h:285]

0x00007ff7e08a8667 TankHead.exe!UNavigationObjectRepository::RegisterNavRelevantObjectInternal() [T:\HEAT\Engine\Source\Runtime\NavigationSystem\Private\NavigationObjectRepository.cpp:120]

0x00007ff7e08bc21d TankHead.exe!UNavigationSystemV1::UpdateNavRelevantObjectInNavOctreeStatic() [T:\HEAT\Engine\Source\Runtime\NavigationSystem\Private\NavigationSystem.cpp:3709]

0x00007ff7e08b90bc TankHead.exe!UNavigationSystemV1::UpdateComponentInNavOctree() [T:\HEAT\Engine\Source\Runtime\NavigationSystem\Private\NavigationSystem.cpp:3804]

0x00007ff7e0e9e843 TankHead.exe!FNavigationSystem::UpdateComponentData() [T:\HEAT\Engine\Source\Runtime\Engine\Private\AI\NavigationSystemBase.cpp:272]

So it looks like a multithread racing condition with sequencer and navigation

[Attachment Removed]

3

Just wanted to mention we’re also having this issue since switching to 5.7

[Attachment Removed]

4

Thank you for bringing this to our attention. What engine version were you using prior to the upgrade? I am trying to track down what may have introduced this crash and that would limit the possible CLs.

-James

[Attachment Removed]

5

Are the callstacks you posted in the thread the other threads that were running when DemandLazyDataGathering from the callstack with the original post happened? I am checking to see if we have some changes that seem likely culprits.

Would it be possible to have the nav relevant objects that are being controlled by Sequencer to toggle off their nav relevancy and then re-enable after the Sequence has ended? Or do you need navmesh for them during the sequence?

-James

[Attachment Removed]

6

[mention removed]​ that is not really going to work, we have so many cinematics with random stuff in it, and going through everything to do this is a huge amount of work. We are just seeing random crashes all over the place and even worse its impossible to tell from the crash what asset is crashing it, so I have to make a development package, reproduce it and than turn it off

[Attachment Removed]

7

I upload a few more log files so you can see what its printing.

[Attachment Removed]

8

I have been discussing this with others on the team. Can you confirm if you are using bDoFullyAsyncNavDataGathering? We have been debugging with that assumption, and one of the team has a fix to potentially try if you are using that. If not, we may need to look at other code paths. The proposed fix for this is in UE5 Main CL# 52486791. Could you please cherrypick that change and let us know the results? I also realize it may take some time to properly say it does work since races can be tricky to repro consistently.

-James

[Attachment Removed]

9

We are indeed using that:

[Image Removed]

[Attachment Removed]

10

Thanks,

I will take a look at it today and report back to see if it fixes it for us!

[Attachment Removed]

11

I just did the test, reverted my disabling of navmesh in the one cutscene we had this 100%, and it came back instantly.

So than I integrated your fix and it seems to have fixed it. I will submit it now into our branch and I have hope this will fix these random crashes :slight_smile:

Thank you very much!

[Attachment Removed]

12

Fantastic! If it does pop back up, please let us know. Or even if it now encounters something slightly different, we want to know.

-James

[Attachment Removed]

13

Hi James,

In our case, we were using 5.6.1.

[Attachment Removed]

14

We were using 5.6.1 as well

[Attachment Removed]