Emulator

Update as 2022/03/14 still exists in 5.0-16101

I have no idea how to reproduce it. If you can provide more information about your system, maybe that'd help.

JMC4789 wrote:

I have no idea how to reproduce it. If you can provide more information about your system, maybe that'd help.

I doubt my system is somehow special. I have Visual Studio. I built Dolphin from source, it happens even with debugger.
It happens at: RenderWidget.cpp, line 65, RenderWidget::SetImGuiKeyMap() calls ImGui::GetIO() that contains this IM_ASSERT.
But ImGui is already destroyed at this point by: RenderBase.cpp, line 1135, Renderer::ShutdownImGui() calls ImGui::DestroyContext().

I'm not sure why state would be Running during shutdown (see RenderWidget line 64), however I see how there could potentially be a race condition here. It should probably verify that the imgui context exists after acquiring the lock in SetImGuiKeyMap().

There's definitely a race condition, as this has happened to me too. But I don't have a way to consistently reproduce it. See https://github.com/dolphin-emu/dolphin/pull/10458 which theoretically may fix it (but in practice I haven't confirmed if it does).

Renderer::InitializeImGui() and Renderer::ShutdownImGui() probably also need to hold the lock (they currently don't) so this works consistently, otherwise it could still potentially get destroyed while it's looping through the keys.

pokechu22 wrote:

There's definitely a race condition, as this has happened to me too. But I don't have a way to consistently reproduce it. See https://github.com/dolphin-emu/dolphin/pull/10458 which theoretically may fix it (but in practice I haven't confirmed if it does).

Well, I can confirm. I patched with fix above, and it works.
I wonder if I'm lucky, but this bug happens 100% of the time to me.
So I can reproduce this consistently.

One other thing is that I think the underlying issue is that imgui is destroyed while GetImGuiLock is not held - but I ran into difficulties changing the relevant code to acquire that lock (I don't remember exactly why, and I might be misremembering).

Why at least this one-line fix "if (!ImGui::GetCurrentContext()) return;" is not implemented yet? I understand that the underlying race condition is not solved, but at least emulator will no longer crash every time you close a game. Temporary solution is better than nothing.

Can you test if https://github.com/dolphin-emu/dolphin/pull/11258 works for you? I would assume it does but just in case.

Can you trace this upwards a bit? Why is the state == Running condition true, where does that signal come from?

Yeah uh no idea. Definitely spooky.

From what I can tell, this has to be something like: There's a call to Core::SetState(Running) that happens shortly before the call to Core::SetState(Stopping), and you're seeing the event from that first call while Core::GetState() already reports the value from the second call.

But here's the thing, where is that call? I've also put a breakpoint there and as far as I can tell the only call to SetState(Running) happens at the start of emulation. So unless that signal is somehow in transit until shutdown (how? is the Qt event thread blocked on your system for the entire emulation, and if yes why?) I don't see where this is even coming from.

Oh, maybe it's "Pause on Focus Loss" setting. It shows a "Do you want to stop?" dialog at exit, I press Yes, then it calls SetState(Running).
If I disable this setting, then there is only one call to SetState(Running) at the start as you say.

I'm pretty sure I've had this issue happen to me with both "pause on lost focus" and "confirm on stop" disabled, but I think that was also with the fifoplayer and not normal games (which means that the shutdown process might be a bit different). Either that or it was something with the Wii shutdown process (where you have to stop emulation twice, with the first one being a "soft" stop that tells the game to shut down, but some games (and in particular homebrew) ignore it).

You said you can't reproduce this crash. What about with "Pause on Focus Loss" setting? Does this setting cause crash only for me? I close with Esc, then press Yes in the "Do you want to stop?" dialog box. Then Dolphin crashes with failed ImGui Assert, because it seems that this dialog box causes focus loss, which tries to pause and resume, and this causes SetState(Running), but ImGui was already destroyed on pressing Yes.

Maybe it's not the missing locks, maybe it's resuming after focus loss after shutdown?