Crashing with error: Loading is stuck, flush will never finish

General Issues and Bug Reporting
,
1

Summary

The project crashes after updating the project from 5.4 to 5.5. Fatal error: Loading is stuck, flush will never finish

Please select what you are reporting on:

Creative

What Type of Bug are you experiencing?

Assets

Steps to Reproduce

Update the project from version 5.4 to 5.5

Expected Result

Normal project loading

Observed Result

The project is crashing. The error code:
[File:D:\build++UE5\Sync\Engine\Source\Runtime\CoreUObject\Private\Serialization\AsyncLoading2.cpp] [Line: 9985]
Loading is stuck, flush will never finish

Platform(s)

Windows 10

2

Same roughly. But the conditions are different.
I case is already occurring as of UE 5.4[Source build ver, engine code unchanged]. and In my win11 environment, this issue has been occurring continue 5.4.x to 5.5.1, and my game build target is a “packaged standalone for WindowsClient” build. However, the UE_LOG output “Loading is stuck, flush will never finish” was not define in the “AsyncLoading2.cpp” source code in 5.4, so the symptom occurred in the form of the launched built game not non error notify, endless never blackscreen. Also, in 5.4 the editor launches correctly and when I launch the game in “PIE Standalone” this issue does not occur.

The topic poster also reported “updating the project from version 5.4 to 5.5”, but this issue also occurs when creating a new blank preset project and non change project data packaging it, so it seems to be a game engine version specific issue and not caused by the project update. At least in my case, I was continue developing games before 5.3 and have not had this problem with the 5.3 version.

I’ve been checking at this issue for the past few months, but why is no one discussing it? I wonder if this is just a not very well known issue that occurs under certain development environments. This issue continuing in the release branch is a fatal. I hope this will be resolved as quickly as possible.

P.S. I am attaching the global=veryverbose logs of building an blank preset UE 5.5 project and experiencing the issue as a standalone build.
Attached log file

1 Like
3

Same issue

trying to migrate project from 5.4.4 to 5.5.1

Fatal error: [File:D:\build++UE5\Sync\Engine\Source\Runtime\CoreUObject\Private\Serialization\AsyncLoading2.cpp] [Line: 9991]
Loading is stuck, flush will never finish

4

Hi I’m having the same issue, does anyone have any tips?

I’ve tried:
-Deleting DDC & Intermediate
-Deleting Saved
-Deleting all plugins
-Opened Blank 5.5 Project
-Restarted
-Deleting the plugins section from my uProject
-Trying on 2 different PCs.

5

Hey for anyone who sees this in the future, here’s how we resolved this.

Download Optional C++ for the engine version
Attach Visual Studio to Unreal as it loads
Breakpoint the crash and work back through the callstack until you find the trouble child, for us, it was the K2 Node - GET Sequence Binding.

We deleted the references to this node in our 5.4.4 project

Opened the project in 5.5.1

Then re-added these nodes back in and it worked just fine.

6

I checked the call stack again, and in my case, the cause seems to be “WorldGridMaterial” in the dumping state of the attached error log, so whether the same procedure can solve the problem may depend on each individual situation. By the way, there seems to be a problem with WorldGridMaterial since 5.4.x, which may be indirectly related to this problem.

Fail to compile Engine WorldGridMaterial (UE 5.4.1)

7

Use Io Store to solve this issue. Project Settings | Packaging | Use Io Store, checked it.

8

You are talking about the “bUseIoStore”, right? That is already enabled in the default settings of the 5.5 blank project, but just to be sure I checked that it was enabled correctly in DefaultGame.ini and then package it, but that didn’t solve the problem.

9

UPDATE: I’ve confirmed that, at least in my environment, the issue has been resolved in the recently released 5.5.3, and the standalone built binaries now run the game properly without getting stuck in the middle. Check it out.

1 Like
11

This issue also occurs in UE5.5.4. If you duplicate the affected asset and replace the reference causing the crash with the new asset, the issue is resolved. However, if you update all references to use the new asset, the same problem occurs again. This workaround causes assets to become bloated and is very troublesome. In our project, we have resolved the issue by duplicating hundreds of assets. We are seeking more information.

1 Like
12

bump

13

Hi there! I’m having the same issue with UE 5.5.4

I just want to make it a little more clear. In my case, which could be similar with yours, I have a data table called DT_Columns. Now, watch the hands:

  1. The class A loads this table in constructor and stores inside TObjectPtr<UDataTable>;
  2. The class B loads it same way and stores same way;

During UE startup routine, the A class constructs successful, but B cause:

Fatal error: [File:D:\build\++UE5\Sync\Engine\Source\Runtime\CoreUObject\Private\Serialization\AsyncLoading2.cpp] [Line: 9991] 
Loading is stuck, flush will never finish

:warning: If we move the any of those loading routine into OnConstruction overloaded method, the error dissapears.

Here we go. If we change TObjectPtr with raw pointer in both classes, the error still appears. I guess the resource just cannot be loaded twice asynchronously or whatever, thanks to epics.
I don’t like the idea to break RAII methodology and move all the loadings inside OnConstruction method, so, the first come in my mind was caching:

TObjectPtr<UDataTable> LoadDataTable(const TCHAR *Path) {
	static TMap<FString, TObjectPtr<UDataTable>> DTCache{};
	static FCriticalSection DTCacheGuard{};

	if (!Path) {
		return nullptr;
	}

	const FScopeLock Lock{ &DTCacheGuard };
	if (auto Found{ DTCache.Find(Path) }; Found && *Found) {
		return *Found;
	}

	if (auto Loaded{ LoadObject<UDataTable>(nullptr, Path) }; Loaded) {
		DTCache.Add(Path, Loaded);
		return Loaded;
	}

	return nullptr;
}

But it doesn’t work. I wish to find an elegant solution, but the only elegant solution could exist is epic’s solution.

So, don’t load things in constructor and try to not load resources twice. Share them somehow

1 Like
15

FORT-938264 changed to ‘Needs More Info’. We’re missing information that would help us determine the source of the issue.