Landscape causes crash in builds in 5.7.4

Development Programming & Scripting
1

It was complety fine in 5.6. Somehow after switching to 5.7.4 worlds with a landscape started to crash in first loading. Instantly crashes the moment landscape loaded. I didn’t change anything about landscape

Here is best log I can get:

Fatal error!

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x0000000000000188

0x00007ff72076e0a9 UAG-Win64-Shipping.exe!ULandscapeComponent::GetCurrentRuntimeMaterialInstanceCount() []
0x00007ff7207b8184 UAG-Win64-Shipping.exe!ULandscapeComponent::GetStreamingRenderAssetInfo() []
0x00007ff721118716 UAG-Win64-Shipping.exe!UPrimitiveComponent::GetStreamingRenderAssetInfoWithNULLRemoval() []
0x00007ff7218e6ce1 UAG-Win64-Shipping.exe!FRenderAssetInstanceState::AddComponentInternal() []
0x00007ff7218e66f1 UAG-Win64-Shipping.exe!FRenderAssetInstanceState::AddComponent() []
0x00007ff7218c0e6c UAG-Win64-Shipping.exe!FLevelRenderAssetManager::IncrementalBuild() []
0x00007ff7218c17e8 UAG-Win64-Shipping.exe!FLevelRenderAssetManager::IncrementalUpdate() []
0x00007ff7218c1a44 UAG-Win64-Shipping.exe!FRenderAssetStreamingManager::IncrementalUpdate() []
0x00007ff7218d21c4 UAG-Win64-Shipping.exe!FRenderAssetStreamingManager::UpdateResourceStreaming() []
0x00007ff7211c3fb5 UAG-Win64-Shipping.exe!FStreamingManagerCollection::UpdateResourceStreaming() []
0x00007ff7211c1874 UAG-Win64-Shipping.exe!FStreamingManagerCollection::Tick() []
0x00007ff7212c22a5 UAG-Win64-Shipping.exe!UGameEngine::Tick() []
0x00007ff721a8bac2 UAG-Win64-Shipping.exe!FEngineLoop::Tick() []
0x00007ff721a8f99f UAG-Win64-Shipping.exe!GuardedMain() []
0x00007ff721a8fa0a UAG-Win64-Shipping.exe!GuardedMainWrapper() []
0x00007ff721a905fd UAG-Win64-Shipping.exe!LaunchWindowsStartup() []
0x00007ff721a96984 UAG-Win64-Shipping.exe!WinMain() []
0x00007ff724aa7cf2 UAG-Win64-Shipping.exe!__scrt_common_main_seh() [D:\a_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
0x00007ffb46117374 KERNEL32.DLL!UnknownFunction []

2

Hello there @LordMegatron666!

Checking around the community, there are cases of certain features causing problem when migrating from 5.6 to 5.7, yet I’m not seeing many like yours.

Reviewing your log, it looks like a null crash. The engine is looking for a pointer or object that doesn’t exist, or it’s corrupted. And it seems to be happening during the streaming phase of the build. Meaning, it’s possible that UE is failing to read your landscape material, or the landscape itself.

So, this is mainly related to the migration, as you changed nothing from your landscape. There are a few methods to test post migration, let’s cover them one by one:

  • First, since your landscape data was baked in 5.6, it needs a rebuild from 5.7. Go to Build, and click on “Build Landscape”. You can also force a refresh by selecting your landscape actor, making a minor change, then re-save all.

  • Another thing to check, if your landscape is using Nanite, try toggling it off and on to force a rebuild. Please do the same for HLODs, if you are using them in your project.

  • For the possible material conflict, I would remove the material from the landscape, reimport/refresh it, then re-assign it back to the landscape. As an extra test, go to Project Settings > Rendering > Textures, and disable “Texture Streaming”.

  • If the crash persists, there could be stale/corrupted data from your previous version still lingering in the cache. To clear that up, go to your project’s main directory, and delete folders DerivedDataCache, Intermediate, and Saved. After that, re-open your project, and allow a full shader recompile.

3

We hit the same issue, but it was intermittent for us (also occurred in a world that was fine in 5.6 but that now crashes on load sometimes in 5.7.4).

We tracked the breaking change to a commit introduced in 5.7 (i.e. confirmed this is a new issue in 5.7 that did not exist in 5.6):

https://github.com/EpicGames/UnrealEngine/commit/503175badc94d69e885f43c9e2eda9cd4ab13096

The crash occurs when transitioning to a World Partition level with a landscape. When a World Partition streaming cell finishes async loading, PostPostLoad fires and the streaming manager’s AddLevel is called - at this point Level->OwningWorld is null because AddToWorld hasn’t run yet.

Later that same frame, IStreamingManager::Tick → IncrementalBuild::ProcessComponents calls GetStreamingRenderAssetInfo on the landscape component, which calls GetCurrentRuntimeMaterialInstanceCount(), which calls GetWorld()->GetFeatureLevel() → null dereference.

This was always a latent window but was harmless before 5.7 because GetStreamingRenderAssetInfo called GetMaterialInstanceCount() / GetMaterialInstance() directly — no world access.

Commit 503175badc94 rerouted those calls through GetCurrentRuntimeMaterialInstanceCount() / GetCurrentRuntimeMaterialInterface() to fix mobile weightmap streaming, which introduced the GetWorld() call into a code path that may run before the world is assigned depending on the race.

We couldn’t find a fix that didn’t require engine source changes. Locally, we have made changes in these two areas:

int32 ULandscapeComponent::GetCurrentRuntimeMaterialInstanceCount() const { ALandscapeProxy* Proxy = GetLandscapeProxy(); const ERHIFeatureLevel::Type FeatureLevel = Proxy->GetWorld()->GetFeatureLevel();

And

class UMaterialInterface* ULandscapeComponent::GetCurrentRuntimeMaterialInterface(int32 InIndex) const { ALandscapeProxy* Proxy = GetLandscapeProxy(); const ERHIFeatureLevel::Type FeatureLevel = GetLandscapeProxy()->GetWorld()->GetFeatureLevel();

In both cases, check if GetWorld() is null, and if it is, skip the feature level check. This works for environments that don’t need the mobile feature level check, but it will regress the original material fix during the race window.

A more-proper fix likely involves a small API change. The original breaking commit that calls into GetCurrentRuntimeMaterialInstanceCount actually already has the feature level safely from the level context:

ERHIFeatureLevel::Type FeatureLevel = LevelContext.GetFeatureLevel(); int32 MaterialInstanceCount = GetCurrentRuntimeMaterialInstanceCount();

It should either pass the feature level into GetCurrentRuntimeMaterialInstanceCount or create a new function that can take the feature level and do the check safely when a world might not currently exist.

Hope this helps.

4

因为英语写作能力不是特别好，需要你用一下translator
我是昨晚出现了一样的问题，步骤是这样的：
1.在OpenLevel中打开了一个世界分区的地图
2.立刻在playercontroller的beginPlay中调用了GetPawn()->SetActorTransform(transform)。
导致了一样的报错，稳定复现，根据3楼的回答，我重新验证了，如果正常游戏的打开是可以正常加载地图保持player处于出生点，并且不会报错。

我推断是如果正常流程在playerStart进行可操控角色生成是没问题的，但是playercontroller的beginPlay中设置transform则不行。

最后的解决方案是重写了gameMode下的ChoosePlayerStart_Implementation函数，直接在目标位置生成了一个APlayerStart，并且返回，避开了错误。

希望对你有帮助。

5

I have the same issue on 5.7.3. One of our maps crashes right after BeginPlay, only in a cooked build (PIE works fine). It is related to setting a camera/pawn to a certain location in BeginPlay or since the 1st Tick.

I tried all the advices above (rebuilding Landscape, turning Nanite on/off, reassigning materials, clearing caches…), but that didn’t help. The only thing that workarounds this issue is disabling texture streaming (-NoTextureStreaming on cmdline).

Another vote for a FIX here. :folded_hands:

Many thanks!
Petr