This is something we ran into while debugging a different hang. To hit it, you need some blueprint event that, when run, will end up calling FlushAsyncLoading to wait for something that will create a new UObject.
We saw it like this:
- Use the ke (kismetevent) command to invoke an event on loaded objects of a particular class.
- This will execute UEngine::HandleKismetEventCommand. It uses FThreadSafeObjectIterator to iterate the object array, looking for matching objects. When it finds one, it calls the named event on it using CallFunctionByNameWithArguments.
- The event (in our case) calls LoadSynchronous to load something from a soft object pointer. This starts loading on the async loading thread, and the game thread waits for this with FlushAsyncLoading.
- On the async loading thread, it loads something that needs to create a new object, which gets added to the engine’s object array.
- Adding the object attempts to lock the array (FUObjectArray::LockInternalArray).
- The game thread already holds the lock (due to the FThreadSafeObjectIterator that’s still active), so the async loading thread blocks until it’s free. But the game thread will never release it, because it’s waiting for async loading to complete.
I have a fix in UEngine::HandleKismetEventCommand that gathers the matching objects first (using FThreadSafeObjectIterator), then calls CallFunctionByNameWithArguments on them in a separate loop that doesn’t hold the object array lock. The relevant code looks like this:
// Call it on all instances of the class
TArray<UObject*> MatchingObjects;
for (FThreadSafeObjectIterator It(ClassToMatch); It; ++It)
{
UObject* const Obj = *It;
UWorld const* const ObjWorld = Obj->GetWorld();
if (ObjWorld == InWorld)
{
MatchingObjects.Add(Obj);
}
}
int32 NumInstanceCallsSucceeded = 0;
for (UObject* Obj : MatchingObjects)
{
const bool bSucceeded = Obj->CallFunctionByNameWithArguments(Cmd, Ar, nullptr, true);
NumInstanceCallsSucceeded += bSucceeded ? 1 : 0;
}
Are there any gotchas here I might be missing? This does solve the deadlock in our repro.
This is a fairly specific issue, but sent us down the wrong path for a while when investigating a different hang, so I also wanted to share it here in case anyone else runs into it.
[Attachment Removed]