Emulator Issues #4602
closed
r7425 leaves the renderer window open (in a weird way) whenever initializing DSP-LLE or the video backend fails.
0%
Description
What steps will reproduce the problem?
- If the Sys\GC directory already contains the dumped DSP files, make at least one of them unavailable to Dolphin (for example by renaming or moving dsp_rom.bin);
- Run Dolphin;
- Press the DSP button under the toolbar, and choose one of the two "DSP LLE" engines instead of HLE;
(4. In this example, I made sure that "Render to Main Window" is unticked in the GFX config window. When ticked, the game list won't appear again unless I go to File->Refresh List (but then it still doesn't accept input from the user); and the "Play" button will be greyed out. Attempting to re-run a game through File->Open seems to fix everything except for the "Emu Thread already running" error.) - Attempt to run any game. Ignore the DSP initialization errors; just pay attention to the renderer window.
What is the expected output? What do you see instead?
I expect the renderer window to be properly closed after failure. Instead, it isn't - its contents turn into grey.
On top of that, attempting to run any game causes Dolphin to spawn a second renderer window, to show "Emu Thread already running" then "Couldn't init the core." (even though the EmuThread has exited already as it was hidden from VS2010), and to destroy the second renderer window.
Dolphin version with the problem? Other Dolphin version without the
problem?
I can reproduce this using my own x86 build of r7598 (compiled and debugged using VS2010), and using Mamario's x86 builds of r7599, r7547, r7435, r7428, r7425.
On the other hand, this issue doesn't occur using Mamario's builds of r7328, r7421 and r7424. This issue is apparently caused by Billiard's r7425.
OS version and versions of tools/libraries used?
Windows 7 Ultimate x86
Please provide any additional information below.
r7425 has moved "error-prone" calls (DSPEmulator::Initialize and VideoBackend::Initialize) from Core::Init() to Core::EmuThread(). Something is either wrong or forgotten when one of the calls errors out.
Also:
{
CFrame::DoFullscreen(false);
// Destroy the renderer frame when not rendering to main
if (!SConfig::GetInstance().m_LocalCoreStartupParameter.bRenderToMain)
CFrame::m_RenderFrame->Destroy();
CFrame::m_RenderParent = NULL;
// Optionally
CFrame::UpdateGUI();
}
Should the above (found in lines 1091 and 929 in file FrameTools.cpp) be made/merged into a new function?
Updated by hatarumoroboshi almost 13 years ago
Wouldn't it be better to have the LLE options greyed out until you put the DSP files in the directory?
Updated by glennricster almost 13 years ago
Hmm. This is caused by revision 7425. Before that revision the DSP backend was initialized before the emulator thread began. That revision seems to have broken some other cases of emulation failure that I had worked to fix before.
Updated by DimitriPilot3 almost 13 years ago
- Status changed from New to Work started
On the one hand, r7607 seems to have taken care of the two error cases described above.
On the other hand, however, there's still another way to create "renderer window leaks", involving the fact that the "Play" button isn't disabled/blocked ASAP upon initializing emulation. Two examples:
Example A¶
Steps 1. 2. 3. 4. and 5. are the same as before, but don't close both error messages yet;
6. In this state, press the "Play" button once again. Another renderer window opens, then we see "Emu Thread already running" and "Could not init the core."
7. Close these two error dialogs, which will close the second renderer window;
8. Now close the other error dialogs from the first renderer window. Notice how it won't close properly, unlike the second one.
9. Now, any time you press the "Play" button, you'll get "Emu Thread already running" and a window that appears and close properly. Thus, this way will allow the "renderer window leak" to occur only once.
Example B¶
Steps 1. 2. 3. 4. 5. and 6. are the same as in example A;
7. Close the error dialogs from the first renderer window, the one with the DSP-LLE errors. This one will close properly;
8. Do the same for the second renderer window. That window will be leaked.
9. Now, notice how pressing "Play" to create another renderer window won't result in "Emu Thread already running" but instead the DSP-LLE initialization errors.
10. This means that by repeating steps 5 through 9, it is possible to leak more windows... This process will stop once you do the mistake of closing out the "Emu Thread already running" errors before the DSP-LLE initialization errors.
Dolphin dislikes having more than one rendering frame created at once, so preventing that from happening should be good. One or two flaws may need to be fixed, the more important one being the one with the "Play" button (the other one being the difference between examples A and B).
Updated by glennricster almost 13 years ago
DimitriPilot3: That is apparently a windows specific issue. On linux dialog modality prevents what you are saying from being able to happen. Even if it did happen on linux, quite frankly I don't care. It is a trivial thing that no one is really going to encounter except in extremely rare cases when they are named DimitriPilot3 and are trying to make it happen. This issue is should be marked as fixed.
Updated by glennricster almost 13 years ago
Sorry to rant, this probably does need to be fixed. Someone on windows should look into it. But I would say this is low priority, as it really is something that most users won't encounter.
Updated by DimitriPilot3 almost 13 years ago
- Status changed from Work started to Fixed
Alright, I admit I wrote too much reproduction details about these "possibly windows-specific, trivial, extremely rare cases", which made the "conclusion" I made rather unclear... (I wrote quite a lot of posts during these days, including bug reports; should probably begin revising for my upcoming (written) French exam)
I guess I'll conclude by saying that this extra problem (and possibly a few other problems due to being able to manage only one pointer/handle) may be avoided, by properly controlling the action of the "Play" button so it doesn't give the possibility of spawning more than one "rendering frame".
This shouldn't be too complex to do, nor windows-specific (easier said than done, however); but yeah, that issue is quite different from the one here, not to mention that this issue mainly focuses on a particular regression... I suppose I'll mark this as fixed, then. (Though I am not sure I am willing to spend some time writing a report for this issue, at least not now...)
Updated by glennricster almost 13 years ago
You should probably leave this issue open until it is properly fixed. It should be noted that we do control the play button. Obviously this particular case is one where it doesn't work right. Although even better than trying to make the play button inactive is to get proper dialog modality working on windows. The main window should not have any interactivity while these dialogs are opened. Unfortunately windows is rather stupid about these things.
Updated by MofoMan2000 almost 13 years ago
It's probably not Windows' fault, per se. Dolphin is almost the only program I've even seen which doesn't have proper dialog modality on Windows. One particular example I can think of is the donation nag dialog in WinRAR.
That being said, this deserves its own issue definitely. 4602 is fixed, but this dialog modality problem is the source of memory leaks. It shouldn't be ignored just because "nobody is going to encounter it".
Updated by glennricster almost 13 years ago
MofoMan2: The dialog modality does not really cause memory leaks. It just causes the ability to do certain GUI things that should not be able to be done while the dialog is open. As to it being windows fault or not, it is always windows fault. :P