UE5.3 build loading broken on linux and windows

Development Platform & Builds
, , ,
1

Hey, really need some help here.
I’ve ported my project from ue 5.2 to .3 recently. and it was all good until i decided to make a build.
the build proceeds fine, but when executed it never loads, it just gets stuck. apparently in a loop of sorts.
i tried building in windows and in linux and in both it has the exact same behavior.

when i tried to hook it into a debugger and stop it, it’s stopped on one of the load pacakges function and if i put a breakpoint it keeps calling it. the only suspicious thing i found in the logs is that it prints this message for every single plugin in my game, all of them.



[2023.09.18-05.55.32:687][  0]LogShaderLibrary: Display: Tried to open shader library 'MediaCompositing', but could not find it neither as a monolithic library nor as a chunked one.
[2023.09.18-05.55.32:687][  0]LogShaderLibrary: Display: Tried to open shader library 'GeometryMode', but could not find it neither as a monolithic library nor as a chunked one.
[2023.09.18-05.55.32:687][  0]LogShaderLibrary: Display: Tried to open shader library 'Metasound', but could not find it neither as a monolithic library nor as a chunked one.
[2023.09.18-05.55.32:687][  0]LogShaderLibrary: Display: Tried to open shader library 'IKRig', but could not find it neither as a monolithic library nor as a chunked one.
[2023.09.18-05.55.32:687][  0]LogShaderLibrary: Display: Tried to open shader library 'AudioSynesthesia', but could not find it neither as a monolithic library nor as a chunked one.
[2023.09.18-05.55.32:687][  0]LogShaderLibrary: Display: Tried to open shader library 'Fab', but could not find it neither as a monolithic library nor as a chunked one.
[2023.09.18-05.55.32:687][  0]LogShaderLibrary: Display: Tried to open shader library 'ControlRig', but could not find it neither as a monolithic library nor as a chunked one.
[2023.09.18-05.55.32:687][  0]LogShaderLibrary: Display: Tried to open shader library 'Sounds', but could not find it neither as a monolithic library nor as a chunked one.
[2023.09.18-05.55.32:687][  0]LogShaderLibrary: Display: Tried to open shader library 'ChaosSolverPlugin', but could not find it neither as a monolithic library nor as a chunked one.
[2023.09.18-05.55.32:687][  0]LogShaderLibrary: Display: Tried to open shader library 'ResonanceAudio', but could not find it neither as a monolithic library nor as a chunked one.

another detail is that i’ve upgraded from

	DefaultBuildSettings = BuildSettingsVersion.V3;
	IncludeOrderVersion = EngineIncludeOrderVersion.Unreal5_2;

to

	DefaultBuildSettings = BuildSettingsVersion.V4;
	IncludeOrderVersion = EngineIncludeOrderVersion.Unreal5_3;

i tried rolling back and doing a full build but it made no difference.

i truly appreciate any help since as it is now my whole project is blocked, and i have many blueprint changes that i need to keep (not compatible with ue5.2.

when debugging using rider it always stays locked in


[LifeDev-Win64-DebugGame.exe] FAsyncLoadingThread2::TickAsyncLoadingFromGameThread(FAsyncLoadingThreadState2 & __ptr64,bool,bool,double,TArrayView<int const ,int>,bool & __ptr64) __ptr64 0x00007ff70761e99c
[LifeDev-Win64-DebugGame.exe] FAsyncLoadingThread2::FlushLoading(TArrayView<int const ,int>) __ptr64 0x00007ff7076043c7
[LifeDev-Win64-DebugGame.exe] FlushAsyncLoading(TArrayView<int const ,int>) 0x00007ff707603158
[LifeDev-Win64-DebugGame.exe] FlushAsyncLoading(int) 0x00007ff707602d8c
[LifeDev-Win64-DebugGame.exe] LoadPackageInternal(UPackage * __ptr64,FPackagePath const & __ptr64,unsigned int,FLinkerLoad * __ptr64,FArchive * __ptr64,FLinkerInstancingContext const * __ptr64,FPackagePath const * __ptr64) 0x00007ff70797c205
[LifeDev-Win64-DebugGame.exe] LoadPackage(UPackage * __ptr64,FPackagePath const & __ptr64,unsigned int,FArchive * __ptr64,FLinkerInstancingContext const * __ptr64,FPackagePath const * __ptr64) 0x00007ff70797b8ac
[LifeDev-Win64-DebugGame.exe] LoadPackage(UPackage * __ptr64,wchar_t const * __ptr64,unsigned int,FArchive * __ptr64,FLinkerInstancingContext const * __ptr64) 0x00007ff70797bb54
[LifeDev-Win64-DebugGame.exe] ResolveName(UObject * __ptr64 & __ptr64,FString & __ptr64,bool,bool,unsigned int,FLinkerInstancingContext const * __ptr64) 0x00007ff70798f457
[LifeDev-Win64-DebugGame.exe] StaticLoadObjectInternal(UClass * __ptr64,UObject * __ptr64,wchar_t const * __ptr64,wchar_t const * __ptr64,unsigned int,UPackageMap * __ptr64,bool,FLinkerInstancingContext const * __ptr64) 0x00007ff70799dd0a
[LifeDev-Win64-DebugGame.exe] StaticLoadObject(UClass * __ptr64,UObject * __ptr64,wchar_t const * __ptr64,wchar_t const * __ptr64,unsigned int,UPackageMap * __ptr64,bool,FLinkerInstancingContext const * __ptr64) 0x00007ff70799d412
[LifeDev-Win64-DebugGame.exe] ConstructorHelpersInternal::FindOrLoadObject<UMaterialParameterCollection>(FString &,unsigned int) 0x00007ff70ebc4309
[LifeDev-Win64-DebugGame.exe] ConstructorHelpers::FObjectFinder<UMaterialParameterCollection>::FObjectFinder<UMaterialParameterCollection>(const wchar_t *,unsigned int) 0x00007ff70ebc770f
[LifeDev-Win64-DebugGame.exe] ULDialogUI::ULDialogUI() 0x00007ff70ebe849d
[LifeDev-Win64-DebugGame.exe] InternalConstructor<ULDialogUI>(const FObjectInitializer &) 0x00007ff70eb7ba82
[LifeDev-Win64-DebugGame.exe] UClass::CreateDefaultObject(void) __ptr64 0x00007ff70764130a
[LifeDev-Win64-DebugGame.exe] FAsyncLoadingThread2::ProcessPendingCDOs(FAsyncLoadingThreadState2 & __ptr64) __ptr64 0x00007ff707612081
[LifeDev-Win64-DebugGame.exe] FAsyncLoadingThread2::TickAsyncLoadingFromGameThread(FAsyncLoadingThreadState2 & __ptr64,bool,bool,double,TArrayView<int const ,int>,bool & __ptr64) __ptr64 0x00007ff70761eb8a
[LifeDev-Win64-DebugGame.exe] FAsyncLoadingThread2::FlushLoading(TArrayView<int const ,int>) __ptr64 0x00007ff7076043c7
[LifeDev-Win64-DebugGame.exe] FlushAsyncLoading(TArrayView<int const ,int>) 0x00007ff707603158
[LifeDev-Win64-DebugGame.exe] FlushAsyncLoading(int) 0x00007ff707602d8c
[LifeDev-Win64-DebugGame.exe] LoadPackageInternal(UPackage * __ptr64,FPackagePath const & __ptr64,unsigned int,FLinkerLoad * __ptr64,FArchive * __ptr64,FLinkerInstancingContext const * __ptr64,FPackagePath const * __ptr64) 0x00007ff70797c205
[LifeDev-Win64-DebugGame.exe] LoadPackage(UPackage * __ptr64,FPackagePath const & __ptr64,unsigned int,FArchive * __ptr64,FLinkerInstancingContext const * __ptr64,FPackagePath const * __ptr64) 0x00007ff70797b8ac
[LifeDev-Win64-DebugGame.exe] LoadPackage(UPackage * __ptr64,wchar_t const * __ptr64,unsigned int,FArchive * __ptr64,FLinkerInstancingContext const * __ptr64) 0x00007ff70797bb54
[LifeDev-Win64-DebugGame.exe] ResolveName(UObject * __ptr64 & __ptr64,FString & __ptr64,bool,bool,unsigned int,FLinkerInstancingContext const * __ptr64) 0x00007ff70798f457
[LifeDev-Win64-DebugGame.exe] StaticLoadObjectInternal(UClass * __ptr64,UObject * __ptr64,wchar_t const * __ptr64,wchar_t const * __ptr64,unsigned int,UPackageMap * __ptr64,bool,FLinkerInstancingContext const * __ptr64) 0x00007ff70799dd0a
[LifeDev-Win64-DebugGame.exe] StaticLoadObject(UClass * __ptr64,UObject * __ptr64,wchar_t const * __ptr64,wchar_t const * __ptr64,unsigned int,UPackageMap * __ptr64,bool,FLinkerInstancingContext const * __ptr64) 0x00007ff70799d412
[LifeDev-Win64-DebugGame.exe] StaticLoadClass(UClass * __ptr64,UObject * __ptr64,wchar_t const * __ptr64,wchar_t const * __ptr64,unsigned int,UPackageMap * __ptr64) 0x00007ff70799cdc9
[LifeDev-Win64-DebugGame.exe] ConstructorHelpersInternal::FindOrLoadClass(FString &,UClass *) 0x00007ff70e12ac52
[LifeDev-Win64-DebugGame.exe] ConstructorHelpers::FClassFinder<UDialogUI>::FClassFinder<UDialogUI>(const wchar_t *) 0x00007ff70ebc6d9f
[LifeDev-Win64-DebugGame.exe] ALDialogMan::ALDialogMan() 0x00007ff70ebcde88
[LifeDev-Win64-DebugGame.exe] InternalConstructor<ALDialogMan>(const FObjectInitializer &) 0x00007ff70eb7b732
[LifeDev-Win64-DebugGame.exe] UClass::CreateDefaultObject(void) __ptr64 0x00007ff70764130a
[LifeDev-Win64-DebugGame.exe] <unknown> 0x00007ff70792a053
[LifeDev-Win64-DebugGame.exe] ProcessNewlyLoadedUObjects(FName,bool) 0x00007ff707907930
[LifeDev-Win64-DebugGame.exe] FEngineLoop::PreInitPostStartupScreen(wchar_t const * __ptr64) __ptr64 0x00007ff70e114a0c
[LifeDev-Win64-DebugGame.exe] GuardedMain(wchar_t const * __ptr64) 0x00007ff70e10df98
[LifeDev-Win64-DebugGame.exe] GuardedMainWrapper(wchar_t const * __ptr64) 0x00007ff70e10e2ea
[LifeDev-Win64-DebugGame.exe] LaunchWindowsStartup(HINSTANCE__ * __ptr64,HINSTANCE__ * __ptr64,char * __ptr64,int,wchar_t const * __ptr64) 0x00007ff70e111196
[LifeDev-Win64-DebugGame.exe] WinMain 0x00007ff70e120d94
[Inlined] [LifeDev-Win64-DebugGame.exe] invoke_main() 0x00007ff71187c9fa
[LifeDev-Win64-DebugGame.exe] __scrt_common_main_seh() 0x00007ff71187c9d9
[kernel32.dll] <unknown> 0x00007ffa5c85257d
[ntdll.dll] <unknown> 0x00007ffa5cdaaa68

which seems to be locked loading a package from one of my classes defaults in cpp.
this was working fine and i did not change it. it seems to me it might be just spinlocking due to the flushasyncloading.
since if you read at the call chain there are 2 flushasyncloading being called one inside the other. i wonder if its just locked waiting for itself.

image
image3347×755 163 KB

2
  1. Missing Dependencies: Ensure that all required dependencies for your build are properly installed on both Linux and Windows systems. Check for any missing libraries or components.
  2. File Path Compatibility: Verify that your file paths and references are consistent and compatible with both operating systems. Use relative paths or consider using a cross-platform build system like CMake.
  3. Compiler Compatibility: Ensure that your codebase and build tools are compatible with the compilers available on both Linux and Windows. Compiler flags and settings may need adjustment.
  4. Version Compatibility: Check if there are any version-specific issues with your development environment, libraries, or frameworks. Ensure that you’re using compatible versions on both platforms.
  5. Cross-Platform Testing: Perform thorough testing on both Linux and Windows environments to identify and address platform-specific issues in your build process.
3

thanks but that’s sounds generic and quite unrelated. as i said the project was working perfectly on 5.2 and when ported to 5.3 it started to fail. i’m pretty sure none of those points apply to this issue.
the bug reproduces on both windows and linux. linux uses clang and windows uses vstudio 2020
but i appreciate it anyway, i might make some tests to pin it down.

4

i just came across the zen loader page by chance and found out about

    -LogCmds="LogStreaming veryverbose"

as i thought there seems to be a sorf of circular dependency on my assets, any idea how to fix this?

LifeDev.log (972.5 KB)

5

Did you fix it? I have the the same issue after upgrading my Lyra based project from 5.2 to 5.3

Seems like the shader library messages are not the main problem here? I just packaged a clean Lyra project and it throws the same messages, but it never seems to freeze on startup. On my project it freezes like 1 out of 4 times or so.
Now I just need to find out what went wrong when copying my stuff over into the Lyra project earlier.

It’s odd though, that it would happen with a clean Lyra project downloaded from the Epic Games Launcher. It’s from a source engine build though. Maybe something is messed up with the engine source then? I guess, I need to make a Launcher editor build as well now :woozy_face:

6

I’ve patched it. i just didn’t loaded the asset because it just so happened that i didn’t need it for now. (means i might have this issue later)
but i do believe this is a bug in the engine. is dead-locking on loading assets due to some sort of circular reference (so it seems to me).

maybe reorganizing your assets, or loading together somewhere else, could help.

1 Like
7

Thanks for the reply! Not an ideal solution unfortunately.
I also tried making a shipping build now of clean Lyra with UE 5.3 both installed right from the launcher and the same issue happens there. Not sure, how this can happen. Did they not test this??
It’s odd though that the freezes don’t seem to happen on my source build with clean Lyra.
Maybe I should avoid this situation completely and revert to 5.2.

8

Having exact problem after upgrading from 5.2 to 5.3, it seems like important bug in the engine, any input from unreal team? tried to look into any logs, no error displayed

1 Like
9

Managed to solve the issue, in my case created empty project in 5.3, copied DefaultEngine.ini from there into my project except params like startup map and removed redirects of the original

1 Like
10

im pretty sure this is not a 100% reproduction rate. i think it depends on the order in which stuff gets processed. (e.g. you add an object and then the order changes)

also im pretty sure it only happens on 5.3

try what i’ve done running with

-LogCmds="LogStreaming veryverbose"

not to my knowledge. i think this should be reported as a bug, but i don’t have the time to do so atm.

1 Like
11

Not exactly the same, but for me since 5.3, my MacOS builds are around 300% larger… is like duplicating the project inside itself 3 times…

12

I had the same issue after updating from 5.2 → 5.3
Replacing the DefaultEngine.ini from a clean project did fix it for me.
I created an empty project, imported my project settings like collision and stuff, and then copied the DefaultEngine.ini, and it now works.

1 Like
13

See PlatformAllowList missing runtime platform gives bizarre errors in logs for my solution to a similar issue.