I got deadlock in my game when alt+tabbing during loading screen, here is some info which may be usefull to fix it in the engine.
MainThread:
> MyGame-Win32-Shipping.exe!FWindowsPlatformProcess::Sleep(float Seconds) Line 984 C++
MyGame-Win32-Shipping.exe!FSlateLoadingSynchronizationMechanism::DestroySlateThread() Line 66 C++
MyGame-Win32-Shipping.exe!FDefaultGameMoviePlayer::WaitForMovieToFinish() Line 244 C++
MyGame-Win32-Shipping.exe!FEngineLoop::Tick() Line 2378 C++
MyGame-Win32-Shipping.exe!GuardedMain(const wchar_t * CmdLine, HINSTANCE__ * hInInstance, HINSTANCE__ * hPrevInstance, int nCmdShow) Line 142 C++
MyGame-Win32-Shipping.exe!GuardedMainWrapper(const wchar_t * CmdLine, HINSTANCE__ * hInInstance, HINSTANCE__ * hPrevInstance, int nCmdShow) Line 137 C++
MyGame-Win32-Shipping.exe!WinMain(HINSTANCE__ * hInInstance, HINSTANCE__ * hPrevInstance, char * __formal, int nCmdShow) Line 200 C++
is waiting for
MainLoop.BlockUntilUnlocked(); in FSlateLoadingSynchronizationMechanism::DestroySlateThread
SlateLoadingThread:
> MyGame-Win32-Shipping.exe!FWindowsPlatformProcess::Sleep(float Seconds) Line 984 C++
MyGame-Win32-Shipping.exe!FSlateLoadingSynchronizationMechanism::SlateThreadRunMainLoop() Line 140 C++
MyGame-Win32-Shipping.exe!FSlateLoadingThreadTask::Run() Line 163 C++
MyGame-Win32-Shipping.exe!FRunnableThreadWin::Run() Line 74 C++
MyGame-Win32-Shipping.exe!FRunnableThreadWin::GuardedRun() Line 26 C++
MyGame-Win32-Shipping.exe!FRunnableThreadWin::_ThreadProc(void * pThis) Line 67 C++
waiting for main thread here FSlateLoadingSynchronizationMechanism::SlateThreadRunMainLoop:
while (IsSlateDrawPassEnqueued())
{
FPlatformProcess::Sleep(0.1f);
}
MainLoop.Unlock();
As you see the MainThread is waiting until SlateLoadingThread release MainLoop spinlock
and the SlateLoadingThread is waiting until MainThread release IsSlateDrawEnqueued thread safe counter
I am trying to reproduce this issue, and so far have not had any luck. Would you be able to provide some additional information?
Does this happen every time you alt-tab away from the loading screen?
It looks like you are using a packaged version of your game, is this correct? If so, did you package in UnrealFrontEnd, or via the Editor?
Are you using a custom loading screen?
Are you able to reproduce this in a brand new project as well? If so, could you provide the exact steps that you are following from project creation to when it gets stuck?
Does this happen every time you
alt-tab away from the loading screen?
It is almost impossible to reproduce this issue, 1/50 tries.
It looks like you are using a packaged
version of your game, is this correct?
If so, did you package in
UnrealFrontEnd, or via the Editor?
Yes it was shipping, I was attached to process and searching another issue non related to slate or loading screen.
The game is packaged with commandline, similiar to this one called by UnrealFrontEnd.
Are you using a custom loading screen?
Yep, I’m using custom loading based on shotergame slate loading screen.
Brush with some hints.
Are you able to reproduce this in a
brand new project as well? If so,
could you provide the exact steps that
you are following from project
creation to when it gets stuck?
I didn’t tried to reproduce this issue on new project - don’t have a time to do this. I believe provided informations are enough to send them to programmer responsible for this code.
As you see Jaroslaw Surowiec wrote:
Potential fix for a deadlock [CL
2566342 by Jaroslaw Surowiec in Main
branch]
I have been trying periodically to reproduce the deadlock that you described, but have so far not been able to do so. Unfortunately, if we cannot reproduce the issue, the best we would be able to do is take a guess at a fix, with no way to be sure it would actually correct the issue. So far I have not seen any evidence of a deadlock occurring.
If you do have an opportunity to provide us with a sample project where you are seeing this deadlock occur, that would be very helpful. Also, if you could please provide the log files when the deadlock next occurs for you, that would be helpful as well. Any additional details that you may have, regardless of how minor they may seem, would also help.
I will be marking this issue as resolved for now, but I will continue to attempt to reproduce the deadlock that you experienced. I will let you know here if I am able to successfully get the deadlock to occur.
I know this is from 2 years but I encounter the exact issue now on 4.16. Exactly at the same place. I use GetGameMoviePlayer()->PlayMovie for loading screen and video. The issue occurs often on XboxOne but I don’t know how it is relevant in this situation. Mainly it is because we now use PlayMovie instead of fullscreen MediaTexture so maybe I will have the same result on another platform.
I start the PlayMovie from C++ code, itself called from Blueprint. Can it be at the origin of the issue ? Doing this kind of stuff from the blueprint VM ?
Should I re-open another thread with the exact same information that gave ?
Sorry for the delayed response. If you are seeing this specifically on the Xbox One, you will want to create a post in the Xbox One section of the forums. That section is restricted to individuals who have been approved to develop for Xbox One, and will help make sure that any Xbox One specific information is not publicly available.
I completely forgot to update my post here. Since then, I searched more in depth and write a new post about it (FScene::UpdateSkyCaptureScene - Infinite wait on dx12 - Cinematics & Media - Epic Developer Community Forums). It seems it was due to the call of the function FSceneUpdateSkyCaptureScene (called at BeginPlay) blocking the render thread, and so blocking IsSlateDrawPassEnqueued, blocking the MainThread during movie playing. The blocking seems to appear when Dx12 is enabled (it works fine in Dx11) so I don’t think this specific to XboxOne but cannot be sure since I do not have Windows 10, so no Dx12 for me on desktop.
Edit : Using custom engine version based on 4.16.3
Hi ,
I don’t think it’s Xbox One specific since I get the exact same issue with a Windows game on UE 4.16.3.
There’s a for the game to hang indefinitely on MainLoop.BlockUntilUnlocked() when alt-tabbing during a loading screen.
I haven’t seen it happening with one of the window modes yet so it would seem it’s somehow related to being in fullscreen mode.
Do you have an approximate estimate for the percentage of times that this occurs? Also, are you seeing this happen with DX12 only as previously mentioned?
I tried packaging the Shooter Game project, and then alt-tabbing out as soon as the loading screen displayed. After several attempts, it did not appear to be running into a deadlock. I did notice that if I alt-tabbed back to the game, it would not accept any input from me, but that did not appear to be a deadlock since the menu selection indicator was slowly pulsing as expected. Would it be possible to get a small test project where you see this deadlock occurring?
It seems loading times in small projects are way too short for this problem to occur. In Shooter Game I have like a split second for alt-tabbing. I also did lose input once but that’s about it, no deadlocks.
FWIW, we hit this frequently in our nightly tests using 4.18.3. It seems to happen when the game is exiting. Same deal with the movie player waiting for the slate thread to finish. Same callstacks all around. I’m not sure how to figure out what is blocking it in our case, but we have seen it on multiple machines.
Sorry for not getting back to you sooner. Is this still something that you are seeing in your project? I was able to find an internal ticket for something that seems very similar to the deadlock that has been described here. Unfortunately no solution was ever found for that ticket, and it was eventually closed due to inactivity. If you are still seeing this, I will see if we can re-open that ticket.
Hi , sorry it took so long for me to get back to you. Technically, we are still seeing this, but I found an awful work around for the time being. During our nightly test, I simply disable the movie player. Its not great, but it worked for my purposes.
