search

SkyTemple / py-desmume

Python Library and GUI for DeSmuME, the Nintendo DS emulator
GNU General Public License v3.0
24 stars 5 forks source link

Memory leak? #23

Closed mike8699 closed 2 years ago

mike8699 commented 2 years ago

I'm using py-desmume to assist with automated testing on my project. I have a series of pytest-driven tests that use py-desmume to open various NDS roms in desmume, control them, inspect their memory contents, etc. I have a singleton instance of desmume.emulator.DeSmuME that I call .open(<rom_path>) on at the start of every test.

This has worked extremely well up to this point, when I had only a couple tests. However, now that the number of tests has grown significantly, I'm running into memory usage issues. Memory usage seems to continuously climb as more roms are opened, almost as if the emulator is not properly "closing" the currently running rom and freeing it from memory. I've collected some metrics below - each time entry represents a new call to DeSmuME.open().

    Time         Memory usage (%)
---------------  ----
23:03:58.733414  23.3
23:04:35.335415  28.8
23:05:13.583826  34.5
23:05:51.558359  40.9
23:06:29.880842  53.8
23:07:08.236224  66.1
23:07:09.310240  66.4
23:07:48.239835  78.3
23:08:27.003041  91.0
23:09:06.626569  94.7
23:09:47.978964  95.7

I did not see any DeSmuME.close() method in the API docs - is there a way to tell py-desmume to close the current ROM and free its memory without calling destroy() on the entire object? If not, I think there may be some sort of memory leaking going on.

theCapypara commented 2 years ago

Hi! I checked this upstream in the interface code and cross-checked it with the GUI for Windows and it seems that everything is done correctly? This seems to be a general memory leak issue in DeSmuME itself then? I will mark this issue was an upstream issue, you might want to consider checking if you can reproduce this with the GUI frontends & opening an issue about this at https://github.com/TASemulators/desmume.

theCapypara commented 2 years ago

Actually I found a function to free the currently loaded ROM, I will add this to the interface code & to py-desmume. Still seems to me like this leak is also present in the GUIs since it doesn't seem to be used when opening a new ROM.

theCapypara commented 2 years ago

Opened a PR: https://github.com/TASEmulators/desmume/pull/518

mike8699 commented 2 years ago

Thanks for the quick action on this! I'll see if I can reproduce this with the desmume GUI and report my findings in the upstream repo.

mike8699 commented 2 years ago

Just to follow up on the specific use case I mentioned in the OP - since upgrading to the latest release (0.0.4.post1 as of this comment), I no longer encounter the memory leak when opening several consecutive roms. In fact, my test suite has 105 tests so far, each of which open a new rom in py-desmume, and the entire test suite runs to completion without any abnormal memory usage 🎉