Memory Leak

[Readek]

Is there an existing issue for this?

• I have searched the existing issues

Affected Build(s)

Latest release

Description of Issue

When playing, the emulator has a small memory leak (about 1MB per second), which becomes an issue when in long sessions (for example, streaming). Tested in Pokemon Y 1.0 and Pokemon X 1.5. Latest release, latest Citra and latest Lime release build all present this issue.

Attached log uses vulkan renderer, though the issue is still present when using OpenGL. This is happening on Linux. I haven't tested on Windows. Log goes up to 1GB before closing the emu.

Expected Behavior

Emu's RAM not consuming my entire PC.

Reproduction Steps

Literally just opening a game and letting it run without doing anything else.

Though in the attached log, I play a battle, then run around for a bit, then I just sit idle.

Log File

citra_log.txt

System Configuration

CPU: AMD Ryzen 5 7600 (12) @ 5.170GHz
GPU/Driver: AMD 7600XT
RAM: 32GB DDR5
OS: Arch Linux

[Miguel-hrvs]

You are right, every second, htop shows that citra adds 1mb without doing anything. We'll have to check if this is an issue from the last original nightly.

citra-memory-leak.mp4

For the moment the only game with this issue is pokemon x and y, others like animal crossing, smash, pokemon moon or ruby doesn't have it.

[MalachiCapela]

From my trace it looks like leak is coming from NeAACDecInit, will post more of what I can find when I get a chance .

[MalachiCapela]

Update:

These seem to be the leaks, memory allocations weren't increasing on initial "Play Game" start menu (when there wasn't any audio to play). But once the Game intro video and song started, the allocations began and keep going at the 1MB per second rate. All the leaks are coming from NeAACDecInit, with NeAACDecInit -> filter_bank_init -> faad_mdct_init -> cffti being the trace.

The line causing the allocations is 107 in aac_decoder.cpp:
auto init_result = NeAACDecInit(decoder, data, data_len, &sample_rate, &num_channels);
then in decoder.c:
hDecoder->fb = filter_bank_init(hDecoder->frameLength);

The actual allocations are in filtbank.c (lines 55-60) in faad2:

    fb_info *fb = (fb_info*)faad_malloc(sizeof(fb_info));
    /* normal */
    fb->mdct256 = faad_mdct_init(2*nshort);
    fb->mdct2048 = faad_mdct_init(2*frame_len);

The faad_mdct_init also allocates more memory when it runs.

I'm not familiar enough with the codebase to identify why the destructor isn't being called or whether too many decoders are being initialized, so sorry I cannot be of more help but I hope this is useful. I'd export the trace as a text format but I grabbed this using MacOS's Instruments which can't export to text format sorry.

Unrelated but is there a working accessible backup of canaries/nightlies around? Want to check it on some previous releases.

[PabloMK7]

That's very useful info, thank you! :D

[rtiangha]

Unrelated but is there a working accessible backup of canaries/nightlies around? Want to check it on some previous releases.

Not sure about older copies, but the final binaries of both can be found on archive.org.

Edit: Actually, if you know the build number of an older build that you want, you might be able to get it off of web.archive.org too. That's how I managed to find a copy of r1800.

So for nightlies, try inputting https://github.com/citra-emu/citra-nightly/releases/tag/nightly-XXXX (or for canaries, https://github.com/citra-emu/citra-canary/releases/tag/canary-XXXX) where XXXX is the build number into web.archive.org and look at different date snapshots; you just might get lucky.

[rtiangha]

Just adding that these are all the nightlies that the Wayback Machine managed to archive (note that they're not in numerical order):

https://web.archive.org/web//https://github.com/citra-emu/citra-nightly/releases/download

[MalachiCapela]

Thank you!

[rtiangha]

Oooh, and Canaries too!

https://web.archive.org/web//https://github.com/citra-emu/citra-canary/releases/download

[SuperErnD]

i dont have that problem

[Z3USI0TA]

Sorry! I don't know programming, forgive me and disregard if I'm wrong.

I tested without the audio and the memory leak continues for me.

I tested with software mode in API Grafico and I don't have a memory leak.

I believe that the leak is in the Graphic code and not in the Audio code

[MalachiCapela]

I am still seeing the leak in software mode but chances are I could be monitoring the wrong thing

[alexdelorenzo]

Seeing this leak on memory constrained ARM devices running Linux, as well.