Assert in `TranslatePriority` from [IOSAppDelegate applicationWillResignActive:]

Development Platform & Builds Mobile
, ,
1

We have intermittent reports in our crash reporter from users. The report say they “just entered” the game (not sure if they mean opened or got into a match).

The relevant code from IOSAppDelegate is:

FGraphEventRef ResignTask = FFunctionGraphTask::CreateAndDispatchWhenReady([]()
{
    FScopeLock ScopeLock(&RenderSuspend);
}, TStatId(), NULL, ENamedThreads::ActualRenderingThread);

And the assert in TaskPrivate.cpp (TranslatePriority) is this:

check(ThreadIndex == ENamedThreads::GameThread || ThreadIndex == ENamedThreads::GetRenderThread() || ThreadIndex == ENamedThreads::RHIThread);

It seems like in CL 39608619 by Ben Zeigler, this assert was changed to be ThreadIndex == ENamedThreads::ActualRenderingThread instead of ThreadIndex == ENamedThreads::GetRenderThread(). Is this a safe change to make in isolation? Should we instead cherry-pick all of CL 39608619? What’s the risk in cherry-picking CL 39608619 if that’s the best route?

Thanks!

2

Steps to Reproduce

3

Hi Jorgen,

Are you trying to use bRunOnAnyThread on FTickFunction? That did not work well at all in 5.5 and you should just upgrade to 5.6 or 5.7 before doing that. If you’re doing something else we’re curious as how you may be hitting that assertion.

Multithreaded ticking was very unsafe in 5.5 and will probably just crash if you try to use it.

Best regards

4

Hi Jorgen,

After tracing through the code on this end, integrating just the assertion from the CL in question should be safe. However, this is masking a separate issue that shouldn’t have any immediate effect on your end and which we’ll look at internally.

Best regards.

5

Hi, we are not explicitly setting `bRunOnAnyThread = true` anywhere. This call stack is from code in `[IOSAppDelegate applicationWillResignActive:]`, which is none of our own code. It seems related to what `ENamedThreads::GetRenderThread()` returns?

The reproduction step is rapidly suspending / resuming the application while first launching it. I’m wondering if there’s a point at which the render thread is not the actual render thread if the suspend happens too early?