Crash when seamlessly travelling from World Partition map (UE-214626)

Hi,

I’ve been running into an issue that sounds very much like UE-214626 and wanted to provide a bit more data in case it helps. Contrary to the issue above, I can reproduce this in editor, but from my testing I see it much more reliably in packaged games.

What I’m trying to achieve is to have a lobby that people can join and from that lobby they start missions together. I want to use seamless travel to achieve this. Unfortunately that seems to crash. I was able to narrow this down to using World Partition maps. If I travel from a basic level lobby to a basic level mission map, I wasn’t able to reproduce. Traveling from an “open world” level to either “open world” or “basic” levels seems to cause the issue.

I was able to reproduce this with UE 5.4.2, but it’s also reproducible on ue5-main, which is what I’ve been using to try and debug this.

There’s a “minimal” test case for this here. Steps to reproduce are:

  • enable seamless travel in PIE (console: “net.AllowPIESeamlessTravel true”)
  • set to play with 2 or more players in PIE

You’ll spawn into the basic lobby by default and can use one of three portals to travel seamlessly to other levels. In my testing I was able to jump between “Basic Mission” and “Basic Lobby” without ever crashing, but when I switch to the “Open World Lobby” and/or “Open World Mission”, that’s where the problems start to happen. Note that it doesn’t always reproduce the first time, but it’s fairly consistent after 4-5 travels.

One thing I noticed early on was this warning message:

[2024.06.24-09.41.35:402][706]LogNet: Warning: Actor None was found in the NetworkObjectList, but is PendingKillPending

This was a bit tricky to debug because this actor was (at least partially) freed most of the time (sometimes the callstack would point towards the Actor->GetName() in that log message). Anyway, I ended up adding a extra layer for debugging that keeps track of actor information and this consistently pointed to the WorldDataLayers object being the bad actor here.

The debugging code I added (it’s not terribly pretty, but serves its purpose) can be found in my development branch here.

1 Like

Hello, did you solve this somehow? I have the same issue even with STANDALONE GAME. Thanks!

Unfortunately I haven’t yet solved this. According to the linked UE issue this is a known problem, so I’m hoping that Epic will be able to fix this (a fix is targetted for 5.5, but so far I haven’t seen a fix for this show up in the ue5-main branch). And yes, I’ve seen this happen not only in PIE but also in standalone and packaged games.

One thing I forgot to add is that the “workaround” mentioned in the issue description (i.e. setting the actor to never be dormant) doesn’t work for me. It does seem to solve the immediate issue, but I see a similar crash happen elsewhere.

To add to this, I debugged it a little bit and found that the crash happens because in UNetDriver::ServerReplicateActors_BuildConsiderList we try to access an object that has already been garbage collected (in my testing it was the WorldDataLayers object, not sure if it is always that one but it seems consistent with the original bug report).

Re-adding the bug number here as this post wasn’t linked to the bug report. UE-214626

Also as another data point for UE-214626 in my case its only happening with 3 or more clients, I haven’t gotten a repro with fewer (4 total players).

And also confirmed its only happening in 5.4, when I revert the upgrade back to 5.3.2 this issue does not occur.

1 Like

I’m having this same issue as well.

Here’s the crash trace i’m getting:

UnrealEditor_Engine!AActor::GetWorld() [D:\build\++UE5\Sync\Engine\Source\Runtime\Engine\Private\Actor.cpp:578]
UnrealEditor_GameplayDebugger!UGameplayDebuggerLocalController::OnDebugDraw() [D:\build\++UE5\Sync\Engine\Source\Runtime\GameplayDebugger\Private\GameplayDebuggerLocalController.cpp:208]
UnrealEditor_GameplayDebugger!V::TBaseUObjectMethodDelegateInstance::ExecuteIfSafe() [D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Public\Delegates\DelegateInstancesImpl.h:667]
UnrealEditor_Engine!UDebugDrawService::Draw() [D:\build\++UE5\Sync\Engine\Source\Runtime\Engine\Private\Debug\DebugDrawService.cpp:93]
UnrealEditor_Engine!UDebugDrawService::Draw() [D:\build\++UE5\Sync\Engine\Source\Runtime\Engine\Private\Debug\DebugDrawService.cpp:76]
UnrealEditor_Engine!UGameViewportClient::Draw() [D:\build\++UE5\Sync\Engine\Source\Runtime\Engine\Private\GameViewportClient.cpp:1954]
UnrealEditor_Engine!FViewport::Draw() [D:\build\++UE5\Sync\Engine\Source\Runtime\Engine\Private\UnrealClient.cpp:1754]
UnrealEditor_UnrealEd!UEditorEngine::Tick() [D:\build\++UE5\Sync\Engine\Source\Editor\UnrealEd\Private\EditorEngine.cpp:2279]
UnrealEditor_UnrealEd!UUnrealEdEngine::Tick() [D:\build\++UE5\Sync\Engine\Source\Editor\UnrealEd\Private\UnrealEdEngine.cpp:550]
UnrealEditor!FEngineLoop::Tick() [D:\build\++UE5\Sync\Engine\Source\Runtime\Launch\Private\LaunchEngineLoop.cpp:5921]
UnrealEditor!GuardedMain() [D:\build\++UE5\Sync\Engine\Source\Runtime\Launch\Private\Launch.cpp:180]
UnrealEditor!GuardedMainWrapper() [D:\build\++UE5\Sync\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:118]
UnrealEditor!LaunchWindowsStartup() [D:\build\++UE5\Sync\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:258]
UnrealEditor!WinMain() [D:\build\++UE5\Sync\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:298]
UnrealEditor!__scrt_common_main_seh() [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
kernel32
ntdll```
1 Like

I have also been able to reproduce the issue, happens with only 1 client connected as well.
From the linked issue tracker entry, set the dormancy to DORM_Never to fix the issue:
In WorldDataLayers.cpp:62, replace
SetNetDormancy(DORM_Initial);
with
SetNetDormancy(DORM_Never);
I have not tested the fix, will test tomorrow.

EDIT: The fix works

This is the same for me as well. I am trying to see what changes were made between 5.3 and 5.4 in seamless travel that would cause this problem.

I think this has now been fixed in the ue5-main branch, possibly in this commit:

commit 81f7d78d5fe24a447dacc59da52e8ad95c502a5d
Author: richard malo <Richard.Malo@epicgames.com>
Date:   Thu Oct 17 10:18:24 2024 -0400

    Removed unnecessary call to AWorldDataLayers::ResetDataLayerRuntimeStates when uninitializing a partition world as it was causing a crash in actor replication.
    #rb jeanfrancois.dube
    #jira UE-197831

    [CL 37226074 by richard malo in ue5-main branch]

At least I don’t see the crashes that I was seeing before after upgrading to a commit after the above and reverting the dormancy change that was posted as a workaround earlier in this thread.

I have had a similar issue UE5.4. Currently trying to seamless travel from a lobby map to game map in PIE. The travel works as expected with 2 players but crashes the engine when attempting the travel with 3 players. This is the stack trace on the crash:

Caught signal 11 Segmentation fault

libUnrealEditor-Engine.so!AActor::GetWorld() const [/opt/UnrealEngine-release/Engine/Source/./Runtime/Engine/Private/Actor.cpp:577]
libUnrealEditor-GameplayDebugger.so!UGameplayDebuggerLocalController::OnDebugDraw(UCanvas*, APlayerController*) [/opt/UnrealEngine-release/Engine/Source/./Runtime/GameplayDebugger/Private/GameplayDebuggerLocalController.cpp:208]
libUnrealEditor-GameplayDebugger.so!TBaseUObjectMethodDelegateInstance<false, UGameplayDebuggerLocalController, void (UCanvas*, APlayerController*), FDefaultDelegateUserPolicy>::ExecuteIfSafe(UCanvas*, APlayerController*) const [/opt/UnrealEngine-release/Engine/Source/Runtime/Core/Public/Delegates/DelegateInstancesImpl.h:665]
libUnrealEditor-Engine.so!void TMulticastDelegateBase<FDefaultDelegateUserPolicy>::Broadcast<IBaseDelegateInstance<void (UCanvas*, APlayerController*), FDefaultDelegateUserPolicy>, UCanvas*, APlayerController*>(UCanvas*, APlayerController*) const [/opt/UnrealEngine-release/Engine/Source/Runtime/Core/Public/Delegates/MulticastDelegateBase.h:254]
libUnrealEditor-Engine.so!UDebugDrawService::Draw(FEngineShowFlags, UCanvas*) [/opt/UnrealEngine-release/Engine/Source/./Runtime/Engine/Private/Debug/DebugDrawService.cpp:93]
libUnrealEditor-Engine.so!UDebugDrawService::Draw(FEngineShowFlags, FViewport*, FSceneView*, FCanvas*, UCanvas*) [/opt/UnrealEngine-release/Engine/Source/./Runtime/Engine/Private/Debug/DebugDrawService.cpp:76]
libUnrealEditor-Engine.so!UGameViewportClient::Draw(FViewport*, FCanvas*) [/opt/UnrealEngine-release/Engine/Source/./Runtime/Engine/Private/GameViewportClient.cpp:1953]
libUnrealEditor-Engine.so!FViewport::Draw(bool) [/opt/UnrealEngine-release/Engine/Source/./Runtime/Engine/Private/UnrealClient.cpp:1752]
libUnrealEditor-UnrealEd.so!UEditorEngine::Tick(float, bool) [/opt/UnrealEngine-release/Engine/Source/./Editor/UnrealEd/Private/EditorEngine.cpp:2276]
libUnrealEditor-UnrealEd.so!UUnrealEdEngine::Tick(float, bool) [/opt/UnrealEngine-release/Engine/Source/./Editor/UnrealEd/Private/UnrealEdEngine.cpp:547]
UnrealEditor!FEngineLoop::Tick() [/opt/UnrealEngine-release/Engine/Source/./Runtime/Launch/Private/LaunchEngineLoop.cpp:5915]
UnrealEditor!GuardedMain(char16_t const*) [/opt/UnrealEngine-release/Engine/Source/./Runtime/Launch/Private/Launch.cpp:182]
libUnrealEditor-UnixCommonStartup.so!CommonUnixMain(int, char**, int (*)(char16_t const*), void (*)()) [/opt/UnrealEngine-release/Engine/Source/./Runtime/Unix/UnixCommonStartup/Private/UnixCommonStartup.cpp:269]
libc.so.6!UnknownFunction(0x2a1c9)
libc.so.6!__libc_start_main(+0x8a)
UnrealEditor!_start()

Furthermore, I’ve piped the execution from command line to a log file and this is the relevant area

[2024.11.15-19.46.41:129][248]LogStats:     SeamlessTravel FlushLevelStreaming  -  0.000 s
[2024.11.15-19.46.41:129][248]LogWorld: Bringing World /Game/Maps/StartMenus/UEDPIE_1_Transition_Level.Transition_Level up for play (max tick rate 0) at 2024.11.15-14.46.41
[2024.11.15-19.46.41:129][248]LogWorld: Bringing up level for play took: 0.000385
[2024.11.15-19.46.41:129][248]LogWorld: Sending NotifyLoadedWorld for LP: LocalPlayer_1 PC: BP_MultiplayerLobby_PlayerController_C_0
[2024.11.15-19.46.41:129][248]LogNet: Verbose: NotifyLoadedWorld Begin
[2024.11.15-19.46.41:129][248]LogNet: VeryVerbose: GetFunctionCallspace RemoteRole Remote ServerNotifyLoadedWorld
[2024.11.15-19.46.41:129][248]LogNetTraffic:       Sent RPC: BP_MultiplayerLobby_PlayerController_C /Game/Maps/StartMenus/UEDPIE_1_Transition_Level.Transition_Level:PersistentLevel.BP_MultiplayerLobby_PlayerController_C_0::ServerNotifyLoadedWorld [52.4 bytes]
[2024.11.15-19.46.41:129][248]LogNetTraffic: VeryVerbose: Sending: FOutBunch: Channel[3] ChSequence: 945 NumBits: 419 PacketId: 0 bOpen: 0 bClose: 0 bIsReplicationPaused: 0 bReliable: 1 bPartial: 0//0//0 bHasPackageMapExports: 0
[2024.11.15-19.46.41:129][248]LogNetTraffic: Verbose: FNetPacketNotify::WriteHeader - Seq 2052, AckedSeq 5751 bReFresh 0 HistorySizeInWords 1
[2024.11.15-19.46.41:129][248]LogNetTraffic: Verbose: UNetConnection::SendRawBunch. ChIndex: 3. Bits: 419. PacketId: 2052
[2024.11.15-19.46.41:129][248]LogNet: Verbose: NotifyLoadedWorld End
[2024.11.15-19.46.41:129][248]LogWorld: StartLoadingDestination to: /Game/Maps/ThirdPersonMap
CommonUnixCrashHandler: Signal=11
[2024.11.15-19.46.41:168][248]LogCore: === Critical error: ===
Unhandled Exception: SIGSEGV: invalid attempt to read memory at address 0x0000000000000008

[2024.11.15-19.46.41:168][248]LogCore: Fatal error!

Can confirm that migrating to 5.5 no longer causes this error.