Strange debug behavior after recent builds and VS 15.7.2

[Zexaron]

Again, many different thing happened, I updated to the latest master, several days worth of dev builds, and VS 15.7.2 update.

I rebuild everything cleanly with user .vs folder clean as well as I was doing general maintenance already as part of an unrelated project (had problems with another repo and nugets, decided to get rid of it and uninstalled Net Core Cross Platform development and some other things not needed for dolphin)

But I also enabled downloading extra symbols from the MS servers this time around (for other unrelated projects mainly), I still tried with "don't load anything unless specified" but it didn't make a difference.

The problem happens with manually running DolphinD.exe as with debugging it inside VS2017.

After starting a game, I tried 3, it loads slowly and keeps saying "Clearing code cache" in the game title, it takes a minute to load and then after it displays logos, it took "Rainbow Six 3" 5 minutes to get to the Main Menu, FPS is low, audio playback is slow and sounds heavily distorted.

That's how it is manually, but debugging in VS it throws an exception inside Assembly, some time after booting, so it doesn't even get to the logos, again showing "Clearing Code Cache" in the title.







I can keep hitting continue and the assembly keeps changing and pointing to new location below ...

EDIT: Well not just debug, you can't use it in practice at all.

[JonnyH]

The dolphin JIT explicitly uses access faults in it's memory emulation - it's likely this interacts poorly with the debugger, as it thinks they're a real failure and doesn't give dolphin's exception handler a chance to fix things up and carry on.

It may be possible to disable fastmem by adding the line "Fastmem = False" to Dolphin.ini under the [Core] section.

That will naturally have a performance impact, as there's a reason dolphin was implemented in this way.

(If that doesn't fix it, then it may be a different problem - I don't really use the windows dev tools, but it's an issue on linux when using the debugger, and I assume these things are implemented in similar ways)

[JosJuice]

You need to make a release build instead of a debug build if you want good performance.

(05-24-2018, 09:33 AM)JonnyH Wrote: It may be possible to disable fastmem by adding the line "Fastmem = False" to Dolphin.ini under the [Core] section.

Yes, but I would suggest to instead just uncheck the "Break when this exception type is thrown" checkbox in the error message Visual Studio shows you.

[Zexaron]

Hmm, it's possible I may have not ever actually started a game while debugging with VS until now.

But I thought the "debug mode" had to be enabled ontop but that's just vague memory, I was always running debug even when launching manually and never experienced this ... I'll keep investigating.

UPDATE: Yeah, I deleted the .suo file which is where the Release build setting gets saved to from the default Debug.

No more problem.

EDIT: I think I was running Debug for some time without noticing because I didn't launch any games.

[JonnyH]

(05-24-2018, 04:11 PM)JosJuice Wrote: You need to make a release build instead of a debug build if you want good performance.


Yes, but I would suggest to instead just uncheck the "Break when this exception type is thrown" checkbox in the error message Visual Studio shows you.

But then theres no point running it under a debugger?

[JosJuice]

(05-25-2018, 01:34 AM)JonnyH Wrote: But then theres no point running it under a debugger?

If you uncheck that checkbox, you mean? VS catches crashes for me even though I've done that (at least most of the time?). And even if it wasn't for catching crashes, running under a debugger still gives you the ability to place breakpoints.

[Zexaron]

Because of this now I found some bug that happens in the debug version, but the bug tracker is down all day. I'm not sure what the policy is on this, whether or not to report and treat debug mode problems the same as if it happened for the general public?

Clicking on "Maker" column in the game list causes this:



Then it throws out to Core\DolphinQt2\Main.cpp line 220.

Tried playing with getting Qt symbols, after researching it looks like it's needs an option to turn on building them from source, but now I see dolphin uses built libs/bins not full source SDK, which is a lot bigger as I installed it for some reason 2 years ago, that's great, then looks like pre-built ones are available https://download.qt.io/archive/qt/5.9/5.9.0/ - took some time finding through the huge zip, so dolphin only needs like 5 DLLs worth of Qt, interesting. I suppose these kinds of errors are nothing special in debug mode right?

Are Qt symbols helpful when dealing with most issues where it's dolphin's fault or generally not needed?