Emulator Issues #13190
closed
Dolphin stops responding when starting a game with `watch` tab enabled
0%
Description
Game Name?
Any, tested with Mario Kart Wii
Game ID? (right click the game in the game list, Properties, Info tab)
RMCP01
MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)
d4408a20d1e29793b0ea4ac3485b4b09
What's the problem? Describe what went wrong.
Dolphin freezes entirely after a few seconds of running a game with the "watch" debugging tab enabled.
This requires a SIGKILL to be sent which KDE prompts me to do after a few seconds of the freeze.
What steps will reproduce the problem?
- Start Dolphin in debugging mode (-d)
- Enable watch tab with "view -> watch"
- Start a game and wait a few seconds.
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
Yes, 18738
Is the issue present in the latest stable version?
No
If the issue isn't present in the latest stable version, which is the first broken version?
Currently do not have the time to bisect, but it is broken at commit 45b55f7ccd19a8f71c7b98d14f00668932a3bf50 and works at commit 4d164fcb77487b0cb732e0423961fd042c3e7e3b
If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer
N/A
What are your PC specifications? (CPU, GPU, Operating System, more)
AMD Ryzen 2600
NVIDIA Geforce RTX 3070
Arch Linux (Kernel 6.2.1-arch1-1)
Using Wayland through KDE, with dolphin running under Xwayland
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
Compiling Dolphin myself from source, so may be an issue with my build environment if not reproducible.
Updated by pokechu22 about 1 year ago
- Regression changed from No to Yes
- Regression start set to 5.0-18644
If I recall correctly, this started with https://github.com/dolphin-emu/dolphin/pull/11554 (5.0-18644). The Watch widget also refreshes continuously in that version, which is useful except that it also means that everything updates continuously when it's open (including e.g. the code widget) for some reason, and to my understanding there isn't explicitly an infinite loop, it's just that the act of pausing the CPU thread to update it the watch widget also causes an event that tells the watch widget to update again.
To my understanding, this doesn't happen for everyone (in particular AdmiralCurtiss mentioned being unable to reproduce it), including the watch widget not live-updating.
Updated by AdmiralCurtiss about 1 year ago
I just didn't make the connection with the Watch widget, you're correct that this starts happening when the Watch widget is enabled.
I think the chain of logic goes somewhat like this:
- WatchWidget::Update() is called through some sequence of action.
- Core::CPUThreadGuard is constructed in WatchWidget::Update(), this calls PauseAndLock().
- CPU::PauseAndLock() sets CPU::s_state to State::Stepping, then waits for the CPU thread to exit from the JIT.
- The CPU thread sees this s_state change and returns from Jit64::Run() to PowerPC::RunLoop().
- PowerPC::RunLoop() calls Host_UpdateDisasmDialog(). This queues an UpdateDisasmDialog() event on the GUI thread. <-- this is key!
- CPU thread informs the waiting GUI thread that it stopped (via s_state_cpu_idle_cvar.notify_all()), then waits for the GUI thread to inform it that it's done with CPU-thread-locked action (via s_state_cpu_cvar.wait()).
- GUI thread gets the signal, exits PauseAndLock() back to WatchWidget::Update(), finishes the GUI update cycle. Once WatchWidget::Update() returns the CPU thread is unlocked and enters its JIT loop again.
- The GUI thread continues updating and eventually reaches the queued UpdateDisasmDialog() event. WatchWidget has registered this event to go to its Update(), so that gets entered, and the cycle repeats...
Updated by pokechu22 about 1 year ago
Oh, I should also clarify: on Windows, it does not hang entirely, but menus take half a second to appear and are generally laggy. It seems reasonable that different platforms would have different behavior (e.g. complete hangs on Linux) as the UI behavior will be different (even if Qt abstracts most of it away).
Updated by AdmiralCurtiss about 1 year ago
I think the best 'fix' for this is probably to suppress UpdateDisasmDialog events during PauseAndLock...?
Updated by JosJuice about 1 year ago
- Status changed from New to Fixed
- Fixed in set to 5.0-18824