[GH-ISSUE #882] [Linux] Once game starts, main UI stops responding

kerem commented

2026-02-27 21:05:21 +03:00

Owner

Originally created by @kavika13 on GitHub (Sep 12, 2024).
Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/882

Once you launch the game, you can no longer interact with the main window. It stops painting. You can move it around, but that's it. If I hit the close button, it doesn't respond, and KDE asks if I want to terminate the app after a few seconds.

This makes it a little annoying to close the emulator, but it also makes it impossible right now to use the cheats feature.

Other people in discord seemed to have the same problem. This happens both if I build from source or if I run a recent AppImage from Actions (usually of someone else's fork or in a branch, because of problems with new PthreadInternal under Linux - but the problem still occurs exactly the same way, whether I apply that patch or not).

Originally created by @kavika13 on GitHub (Sep 12, 2024). Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/882 Once you launch the game, you can no longer interact with the main window. It stops painting. You can move it around, but that's it. If I hit the close button, it doesn't respond, and KDE asks if I want to terminate the app after a few seconds. This makes it a little annoying to close the emulator, but it also makes it impossible right now to use the cheats feature. Other people in discord seemed to have the same problem. This happens both if I build from source or if I run a recent AppImage from Actions (usually of someone else's fork or in a branch, because of problems with `new PthreadInternal` under Linux - but the problem still occurs exactly the same way, whether I apply that patch or not).

kerem

2026-02-27 21:05:21 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-27 21:05:22 +03:00

Author

Owner

@kavika13 commented on GitHub (Sep 20, 2024):

I poked around in the code a bit, and I believe this is due to the QT event loop and SDL event loop both being written so they block their thread in a loop, and both want to run on the main thread.

I think this could be fixed by pulling the SDL event dispatch code outside the loop, and making it callable directly from the QT app. The QT app could dispatch events to it and be happy, and the command line executable could have a loop and dispatch to that function and also be happy.

@kavika13 commented on GitHub (Sep 20, 2024): I poked around in the code a bit, and I believe this is due to the QT event loop and SDL event loop both being written so they block their thread in a loop, and both want to run on the main thread. I think this could be fixed by pulling the SDL event dispatch code outside the loop, and making it callable directly from the QT app. The QT app could dispatch events to it and be happy, and the command line executable could have a loop and dispatch to that function and also be happy.

kerem commented

2026-02-27 21:05:22 +03:00

Author

Owner

@rtwair commented on GitHub (Nov 22, 2024):

Same issue here... I wonder if there is a hack we can do in the meantime to pause the main game thread to ensure the UI is responsive and that SDL events are still processed properly without locking the UI thread? Eager to test out cheats.

@rtwair commented on GitHub (Nov 22, 2024): Same issue here... I wonder if there is a hack we can do in the meantime to pause the main game thread to ensure the UI is responsive and that SDL events are still processed properly without locking the UI thread? Eager to test out cheats.

kerem commented

2026-02-27 21:05:22 +03:00

Author

Owner

@rtwair commented on GitHub (Dec 2, 2024):

@Hermiten, I’d classify this as a bug rather than an enhancement because certain functionalities, like cheats, can’t be utilized since the UI is unresponsive while the game is running

@rtwair commented on GitHub (Dec 2, 2024): @Hermiten, I’d classify this as a bug rather than an enhancement because certain functionalities, like cheats, can’t be utilized since the UI is unresponsive while the game is running

kerem commented

2026-02-27 21:05:22 +03:00

Author

Owner

@C0rn3j commented on GitHub (Dec 19, 2024):

@kavika13 are you sure it's just freezing for you and not crashing a thread and hanging?

If it's dumping it would be a dupe of https://github.com/shadps4-emu/shadPS4/issues/1720 - which is newer, but it has a stack trace.

Could also now be dumping for you too if it was previously freezing, on the current codebase.

@C0rn3j commented on GitHub (Dec 19, 2024): @kavika13 are you sure it's just freezing for you and not crashing a thread and hanging? If it's dumping it would be a dupe of https://github.com/shadps4-emu/shadPS4/issues/1720 - which is newer, but it has a stack trace. Could also now be dumping for you too if it was previously freezing, on the current codebase.

kerem commented

2026-02-27 21:05:22 +03:00

Author

Owner

@morten71 commented on GitHub (Dec 20, 2024):

I'm having this problem too: The Qt app becomes unresponsive, the moment I start a game. I don't see a dump/crash until I close the game window.

I obviously don't understand much of what is going on, so I may be getting this completely wrong, but looking at the code I don't understand how it could behave otherwise:

The QT code at qt_gui/main_window.cpp:586 calls emulator.Run(path) which never returns. Because at src/emulator.cpp:277 the emulator enters the SDL event loop that never exits, until the emulation stops (when the game window is closed).

This seems to be the same conclusion kavika13 came to earlier.

Closing the game window I do get a crash, when the emulator.Run function exits the SDL event loop and ends up calling std::exit(0) without ever returning control to QT.

On the console I just end up getting:

Lib.Ajm] <Info> ajm.cpp:sceAjmBatchCancel:42: called context_id = 1 batch_id = 1
[Render.Vulkan] <Info> vk_pipeline_cache.cpp:CompileModule:491: Compiling fs shader 0xcfa96da9 
[Render.Vulkan] <Info> vk_pipeline_cache.cpp:CompileModule:491: Compiling vs shader 0xbb4d5f8c 
[Render.Vulkan] <Info> vk_pipeline_cache.cpp:CompileModule:491: Compiling fs shader 0xfc52ba5e 
[Render.Vulkan] <Info> vk_pipeline_cache.cpp:CompileModule:491: Compiling vs shader 0x9951d199 
[Render.Vulkan] <Info> vk_pipeline_cache.cpp:CompileModule:491: Compiling vs shader 0x44072322 
[Loader] <Info> emulator.cpp:UpdatePlayTime:400: Playing time for CUSA03173: 23:09:19
Segmentation fault

And I haven't figured out how to get it running with gdb. When I try, I just get a completely different crash a lot earlier, while the game is starting, and the back trace is useless, with all ??? instead of function names, even though the executable does seem to contain debugging symbols (probably something simple I'm doing wrong, but like I said I don't understand much :D)

I'm attaching my shad_log.txt file
shad_log.txt

@morten71 commented on GitHub (Dec 20, 2024): I'm having this problem too: The Qt app becomes unresponsive, the moment I start a game. I don't see a dump/crash until I close the game window. I obviously don't understand much of what is going on, so I may be getting this completely wrong, but looking at the code I don't understand how it could behave otherwise: The QT code at qt_gui/main_window.cpp:586 calls emulator.Run(path) which never returns. Because at src/emulator.cpp:277 the emulator enters the SDL event loop that never exits, until the emulation stops (when the game window is closed). This seems to be the same conclusion kavika13 came to earlier. Closing the game window I do get a crash, when the emulator.Run function exits the SDL event loop and ends up calling std::exit(0) without ever returning control to QT. On the console I just end up getting: ``` Lib.Ajm] <Info> ajm.cpp:sceAjmBatchCancel:42: called context_id = 1 batch_id = 1 [Render.Vulkan] <Info> vk_pipeline_cache.cpp:CompileModule:491: Compiling fs shader 0xcfa96da9 [Render.Vulkan] <Info> vk_pipeline_cache.cpp:CompileModule:491: Compiling vs shader 0xbb4d5f8c [Render.Vulkan] <Info> vk_pipeline_cache.cpp:CompileModule:491: Compiling fs shader 0xfc52ba5e [Render.Vulkan] <Info> vk_pipeline_cache.cpp:CompileModule:491: Compiling vs shader 0x9951d199 [Render.Vulkan] <Info> vk_pipeline_cache.cpp:CompileModule:491: Compiling vs shader 0x44072322 [Loader] <Info> emulator.cpp:UpdatePlayTime:400: Playing time for CUSA03173: 23:09:19 Segmentation fault ``` And I haven't figured out how to get it running with gdb. When I try, I just get a completely different crash a lot earlier, while the game is starting, and the back trace is useless, with all ??? instead of function names, even though the executable does seem to contain debugging symbols (probably something simple I'm doing wrong, but like I said I don't understand much :D) I'm attaching my shad_log.txt file [shad_log.txt](https://github.com/user-attachments/files/18209876/shad_log.txt)

kerem commented

2026-02-27 21:05:22 +03:00

Author

Owner

@ngoquang2708 commented on GitHub (Dec 20, 2024):

Try this https://github.com/shadps4-emu/shadPS4/pull/1829.

@ngoquang2708 commented on GitHub (Dec 20, 2024): Try this https://github.com/shadps4-emu/shadPS4/pull/1829.

kerem commented

2026-02-27 21:05:22 +03:00

Author

Owner

@morten71 commented on GitHub (Dec 20, 2024):

Try this #1829.

This fixes the problem. The QT app does not become unresponsive now. And I can get to the cheats list, and when I enable a cheat, I get

[Loader] <Info> memory_patcher.cpp:PatchMemory:398: Applied patch: Infinite Health, Offset: 38684034551, Value: C787F8000000FFFFFF7F90

in the terminal.

The only thing now, is that when I try to close the game window, everything freezes. The game window does not close, and the game sound keeps playing. The SDL event loop does exit, and the UpdatePlayTime function gets called. I'm guessing the std::exit(0) call doesn't play well with running in a thread maybe?

But the QT app freezing problem is definitely solved by this :D

@morten71 commented on GitHub (Dec 20, 2024): > Try this #1829. This fixes the problem. The QT app does not become unresponsive now. And I can get to the cheats list, and when I enable a cheat, I get `[Loader] <Info> memory_patcher.cpp:PatchMemory:398: Applied patch: Infinite Health, Offset: 38684034551, Value: C787F8000000FFFFFF7F90` in the terminal. The only thing now, is that when I try to close the game window, everything freezes. The game window does not close, and the game sound keeps playing. The SDL event loop does exit, and the UpdatePlayTime function gets called. I'm guessing the std::exit(0) call doesn't play well with running in a thread maybe? But the QT app freezing problem is definitely solved by this :D

kerem commented

2026-02-27 21:05:22 +03:00

Author

Owner

@kavika13 commented on GitHub (Dec 22, 2024):

The fix in PR #1829 solves the problem as initially stated in my original report. I can use cheats and the window is responsive.

There may need to be additional fixes for stuff like handling close events properly, but I think those already don't work super well, and I don't think PR #1829 makes that any worse. That statement could stand to be verified. But if it's accurate, I think it could be a separate ticket and PR to address those, even though I did mention them in my OP.

@kavika13 commented on GitHub (Dec 22, 2024): The fix in PR #1829 solves the problem as initially stated in my original report. I can use cheats and the window is responsive. There may need to be additional fixes for stuff like handling close events properly, but I think those already don't work super well, and I don't think PR #1829 makes that any worse. That statement could stand to be verified. But if it's accurate, I think it could be a separate ticket and PR to address those, even though I did mention them in my OP.

Rows
Columns

[GH-ISSUE #882] [Linux] Once game starts, main UI stops responding #251