Emulator

Memory usage for me is totally flat over a 15+ minute period. 5.0-17150, Intel i5-4670k, Intel HD Graphics 4600, Windows 10 1903.

If you aren't already using this, try creating an empty file "portable.txt" in the same directory as Dolphin.exe. This will cause Dolphin to create and use a new config folder (in a different location from your normal one) which will make it behave like a fresh install. Once you're done testing with that setup you can delete portable.txt to get back your normal settings.

Can you check 5.0-16380, which uses Qt 5 instead of Qt 6?

pokechu22 wrote:

Can you check 5.0-16380, which uses Qt 5 instead of Qt 6?

I have checked this version using the portable.txt, and it has the same behavior right down to happening immediately before press yes/no for usage stats. It grows at about the same rate as 5.0-17150.

godisgovernment wrote:

on latest dev build, can you let dolphin run for a bit (so memory growth is obvious), then create a dump of dolphin with task manager, compress, and upload the dump somewhere (google drive, etc).

Sure. I'll let it get to about 1 gig and then do a dump. To be clear you want a .DMP file that Task manager produces? If so I will upload the dump to my Google Drive and post the link here.

yes that's correct. compressing the file first should make it a lot smaller.

Ok, I got the dump file uploaded to Google Drive and it's ready to go. I did compress it, I hope you are ok with .7z. If not I can re-compress it to a different format. the original file size was around 1.2 gigs. Please let me know if the link does not work.

https://drive.google.com/drive/folders/1BKrSYbE9mGZ9RV_cX7-7bO8AKcmg4OpR?usp=sharing

thanks. can you try these 2 versions:
https://dolphin-emu.org/download/dev/master/5.0-16211/
https://dolphin-emu.org/download/dev/master/5.0-16214/
if my guess is correct, you should see the problem in 5.0-16214 but not 5.0-16211

godisgovernment wrote:

thanks. can you try these 2 versions:
https://dolphin-emu.org/download/dev/master/5.0-16211/
https://dolphin-emu.org/download/dev/master/5.0-16214/
if my guess is correct, you should see the problem in 5.0-16214 but not 5.0-16211

You are correct. 5.0-16214 has the issue, it's ram usage keeps expanding. 5.0-16211 does not, it's ram consumption stays static.

What's the issue?

For some reason dolphin's Windows.Gaming.Input-related code is causing a lot of COM allocations to build up without getting free'd. I'm not sure why yet. In the meantime, some more things you can try (on the latest dev version/with the bug):

• unplug your Xbox One controller and see if it still happens
• temporarily disable the "DisplayFusion" software (maybe just rename C:\Program Files (x86)\DisplayFusion\Hooks\AppHook64_EB371455-88BD-4926-95BA-5E0372A3FD46.dll to something else before running dolphin).

but, hopefully it's just a simple bug in dolphin's code.

p.s. you could also try looking at dolphin's log for input-related stuff (when the controller is plugged in and you see the memory leak). maybe something useful is getting spammed in there

Unplugging my Xbox One controller does in fact fix the issue, but now it's very difficult to play :P.

When I unplug the controller and then start dolphin, the constant ram consumption does not occur. I tried this with both displayfusion on and off including the running service, and the result is the same. If you start Dolphin with the Xbox One controller plugged in, Dolphin will increase in ram consumption until you kill it. Even if you unplug the controller after launching dolphin, the ram will usage will continue to expand at the same rate.

However, if you plug in the controller after dolphin has started, it will only increase the used ram slightly once or twice, but never again.

I haven't tried loading a game, or anything else past this point, but I can if you would like. I can try other controllers as well. Let me know what you think.

godisgovernment wrote:

p.s. you could also try looking at dolphin's log for input-related stuff (when the controller is plugged in and you see the memory leak). maybe something useful is getting spammed in there

Where can I find Dolphin's log?

thanks. unfortunately nothing in the log makes the error obvious, so i'll starting picking over the code and let you know if i have something to test. I don't have xbox one controller but maybe it will repro with a different controller as well (it is sort of a problem that people aren't likely to notice, so maybe it's been happening often but no one realized it).

So I have a few controllers around the house that I was willing to test just for the sake of thoroughness. TL;DR Only the Xbox One controller is causing the issue.

Xbox One Controller: Issue

8Bitdo SNES controller: No Issue
8Bitdo 6button "M30" Genesis Controller: No Issue
Steam Controller: No Issue
Strange Chinese N64 to USB Converter: No Issue
PS4 Controller using DS4Windows: No Issue

I think we can focus on the Xbox One controller being the culprit.

fwiw, we've tracked it down to this pointer getting leaked: https://github.com/dolphin-emu/dolphin/blob/7b2b559743f09d2b087728d7eb0c14c6b81a9f2a/Source/Core/InputCommon/ControllerInterface/WGInput/WGInput.cpp#L538
if you really want to fix it now, you could compile a version of dolphin that returns from UpdateBatteryLevel without doing anything (and fake or ignore the m_battery_level), or maybe figure out how to properly free report/call TryGetBatteryReport :)

Thank you so much for putting a lot of effort into this. As much as I'd love to have it fixed now, I understand these things take time. I have a lot of RAM, so I never really ran into an issue while gaming. My immediate need to use an Xbox One controller is diminished somewhat by having a lot of controller options. The only reason I noticed was by accident, though I'm sure this probably does create an issue when it comes to performance, and becomes much more of an issue on less beefy machines. Running out of memory isn't fun, and making my page file big isn't good either when it comes to my SSD's health.

While I am somewhat tech savvy (I do IT for a living), and feel pretty comfortable scripting/using a terminal/CLI etc, programing is largely above my ability, not to mention that I am not familiar with this code base at all.

I don't know if this is possible, but could you implement a bypass for checking the battery while a controller is plugged in? For the record, there are no batteries in my Xbox One controller; I only use it wired. I understand it is pretty handy to know when your controller is fully charged, but it seems unnecessary when you are using a wired controller. It's probably not a good solution to do it that way though.

Thanks again for your diligence.

could you see if this build fixes it for you https://dl.dolphin-emu.org/prs/49/2d/pr-10964-dolphin-latest-x64.7z

godisgovernment wrote:

could you see if this build fixes it for you https://dl.dolphin-emu.org/prs/49/2d/pr-10964-dolphin-latest-x64.7z

Unfortunately it does not. The behavior is the same.

sad :'( could you please try this one? https://dl.dolphin-emu.org/prs/da/a5/pr-10966-dolphin-latest-x64.7z (note: i've disabled SDL in there, so it not being available is expected)

godisgovernment wrote:

sad :'( could you please try this one? https://dl.dolphin-emu.org/prs/da/a5/pr-10966-dolphin-latest-x64.7z (note: i've disabled SDL in there, so it not being available is expected)

This has the same undesirable behavior as well.

This is unfortunately a bug in the Windows.Gaming.Input.dll of Windows.

GameController::TryGetBatteryReport calls BatteryReport::RuntimeClassInitialize, which constructs the BatteryReport object. Internally it holds 2 refcounted int32 objects, one of which it leaks a reference to. Dolphin could do some hacky things to work around it, but it's probably better to either ignore the memleak for now or disable the battery polling code for WGI.

Well if this is a Windows issue, I don't think it's something we can fix directly. For me, with 32 gigs of ram, it is somewhat easy to ignore the ram usage as my gaming sessions, so far, have not lasted long enough to fill it up completely. I only really noticed by accident. Alternatively, I can use a different controller that doesn't produce the issue if it is necessary, though I am sure others might not be as fortunate as me to own that many devices.

I don't know the ramifications of disabling the battery polling code, so while I'd like to say that's the better approach, it's hard for me to really know. I would say a memory leak is worse but if the battery percentage is necessary in any case, the memory leak is the lesser of two evils, as I can still use dolphin with the memory leak.

Is there a way to report this to Microsoft? I'm also curious if their new "Xbox Core Controller" has the same issue, though I am unable to test that as I don't own one.

I've reported the bug to Windows.

This PR goes over some of the details: https://github.com/dolphin-emu/dolphin/pull/10966 (the build is https://dl.dolphin-emu.org/prs/da/a5/pr-10966-dolphin-latest-x64.7z - download again as it changed from last time). Currently I have a hack-fix in the PR which fixes the leaking problem. The dolphin team still needs to decide whether to use the hack-fix, just disable battery reporting for WGI, or something else.

In any case, work on this issue is done i think. thanks for reporting and testing stuff.

The workaround was merged too.

oh cool