Memory leak in "save and restore" feature in "Retroplayer". Who can debug/fix this?
#1
Hello,

I've first found this problem in snes9x, but it also exists in other emulation backends:
https://github.com/kodi-game/game.libret.../issues/15

If you exit a game and reopen it, then there is a chance that Kodi starts to "eat" memory really fast. This is not really a memory leak as the memory is freed again if you exit the game fast enough. But it also doesn't have any end. If noone stops Kodi from eating memory it will fill RAM, then Swap and then you have to hard-reset your frozen system.

To work around this issue, I've configured systemd to kill and restart Kodi if it uses more than 75% of system memory.

Would be great if someone could have a deeper look into this.
Reply
#2
This seems to be a problem with snes9x. When a savestate is restored, it clobbers existing memory and leaves some unfreed. Can you try disabling auto-save in the game settings?
BTC: 1JtXwJdGdE9YnYgThWBT2StFCU5sEYkbVD (personal), https://kodi.tv/contribute/donate-bitcoin (foundation). Donations in the form of controllers, especially ones that don't work in Kodi, are also appreciated.
Reply
#3
I'm no longer using snes9x. I've uninstalled it and I'm using bsnes-mercury-performance now.
See https://github.com/kodi-game/game.libret...-475566443

The problem can be reproduced with bsnes-mercury-performance even easier.
I used "massif" to get a rough idea where the memory is wasted. I guess the interesting part is:

--------------------------------------------------------------------------------
  n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
--------------------------------------------------------------------------------
 48 106,524,319,774    2,670,237,304    2,664,575,366     5,661,938            0
99.79% (2,664,575,366B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->95.11% (2,539,651,072B) 0x139F556: void std::vector<KODI::RETRO::CDeltaPairMemoryStream::DeltaPair, std::allocator<KODI::RETRO::CDeltaPairMemoryStream::DeltaPair> >::_M_realloc_insert<KODI::RETRO::CDeltaPairMemoryStream::DeltaPair const&>(__gnu_cxx::__normal_iterator<KODI::RETRO::CDeltaPairMemoryStream::DeltaPair*, std::vector<KODI::RETRO::CDeltaPairMemoryStream::DeltaPair, std::allocator<KODI::RETRO::CDeltaPairMemoryStream::DeltaPair> > >, KODI::RETRO::CDeltaPairMemoryStream::DeltaPair const&) (in /usr/lib/kodi/kodi-x11)
| ->95.11% (2,539,651,072B) 0x139F196: KODI::RETRO::CDeltaPairMemoryStream::SubmitFrameInternal() (in /usr/lib/kodi/kodi-x11)
|   ->95.11% (2,539,651,072B) 0x13B1B84: KODI::RETRO::CReversiblePlayback::AddFrame() (in /usr/lib/kodi/kodi-x11)
|     ->95.11% (2,539,651,072B) 0x13B0781: KODI::RETRO::CGameLoop::Process() (in /usr/lib/kodi/kodi-x11)
|       ->95.11% (2,539,651,072B) 0xF68823: CThread::Action() (in /usr/lib/kodi/kodi-x11)
|         ->95.11% (2,539,651,072B) 0xF694C7: CThread::staticThread(void*) (in /usr/lib/kodi/kodi-x11)
|           ->95.11% (2,539,651,072B) 0x485CA9B: start_thread (in /usr/lib/libpthread-2.28.so)
|             ->95.11% (2,539,651,072B) 0x6F81B21: clone (in /usr/lib/libc-2.28.so)
|               
->04.68% (124,924,294B) in 5001 places, all below massif's threshold (1.00%)

I kept a backup of this log in case someone needs it.

The percentage number in front keeps increasing in my log. There is no single mentioning about the emulation backend here.

The memory "somehow" isn't lost. Exiting from the game immediately frees all these gigabytes of wasted memory.

Can someone use this information to at least give some instructions on how to debug further?

Is there some other discussion platform about Kodi development? This forum seems to be at least partially dead.
Reply
#4
(2019-04-09, 14:43)M-Reimer Wrote: I'm no longer using snes9x. I've uninstalled it and I'm using bsnes-mercury-performance now.
See https://github.com/kodi-game/game.libret...-475566443

The problem can be reproduced with bsnes-mercury-performance even easier.
I used "massif" to get a rough idea where the memory is wasted. I guess the interesting part is:

--------------------------------------------------------------------------------
  n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
--------------------------------------------------------------------------------
 48 106,524,319,774    2,670,237,304    2,664,575,366     5,661,938            0
99.79% (2,664,575,366B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->95.11% (2,539,651,072B) 0x139F556: void std::vector<KODI::RETRO::CDeltaPairMemoryStream:Big GrineltaPair, std::allocator<KODI::RETRO::CDeltaPairMemoryStream:Big GrineltaPair> >::_M_realloc_insert<KODI::RETRO::CDeltaPairMemoryStream:Big GrineltaPair const&>(__gnu_cxx::__normal_iterator<KODI::RETRO::CDeltaPairMemoryStream:Big GrineltaPair*, std::vector<KODI::RETRO::CDeltaPairMemoryStream:Big GrineltaPair, std::allocator<KODI::RETRO::CDeltaPairMemoryStream:Big GrineltaPair> > >, KODI::RETRO::CDeltaPairMemoryStream:Big GrineltaPair const&) (in /usr/lib/kodi/kodi-x11)
| ->95.11% (2,539,651,072B) 0x139F196: KODI::RETRO::CDeltaPairMemoryStream::SubmitFrameInternal() (in /usr/lib/kodi/kodi-x11)
|   ->95.11% (2,539,651,072B) 0x13B1B84: KODI::RETRO::CReversiblePlayback::AddFrame() (in /usr/lib/kodi/kodi-x11)
|     ->95.11% (2,539,651,072B) 0x13B0781: KODI::RETRO::CGameLoop:Tonguerocess() (in /usr/lib/kodi/kodi-x11)
|       ->95.11% (2,539,651,072B) 0xF68823: CThread::Action() (in /usr/lib/kodi/kodi-x11)
|         ->95.11% (2,539,651,072B) 0xF694C7: CThread:ConfusedtaticThread(void*) (in /usr/lib/kodi/kodi-x11)
|           ->95.11% (2,539,651,072B) 0x485CA9B: start_thread (in /usr/lib/libpthread-2.28.so)
|             ->95.11% (2,539,651,072B) 0x6F81B21: clone (in /usr/lib/libc-2.28.so)
|               
->04.68% (124,924,294B) in 5001 places, all below massif's threshold (1.00%)

I kept a backup of this log in case someone needs it.

The percentage number in front keeps increasing in my log. There is no single mentioning about the emulation backend here.

The memory "somehow" isn't lost. Exiting from the game immediately frees all these gigabytes of wasted memory.

Can someone use this information to at least give some instructions on how to debug further?

Is there some other discussion platform about Kodi development? This forum seems to be at least partially dead.

This very well might be a problem in RetroPlayer. It could also be the savestate feature, which buffers memory states for 1min. Does the memory stop increasing after a minute? Does this behavior go away if you disable rewind in Game Settings?
BTC: 1JtXwJdGdE9YnYgThWBT2StFCU5sEYkbVD (personal), https://kodi.tv/contribute/donate-bitcoin (foundation). Donations in the form of controllers, especially ones that don't work in Kodi, are also appreciated.
Reply
#5
The HTPC will not survive a minute. Memory just fills too fast.
I'll try disabling rewind this weekend.
Reply
#6
I did a few tries and could, so far, not reproduce the bug with "Rewind" disabled.

I'll do some more tests and try with "Rewind" enabled and disabled just to be really sure it is caused by this, but it seems like this is a good start. I could live with "Rewind" disabled. Didn't use this so far. But, of course, this feature should be fixed...
Reply
 
Thread Rating:
  • 0 Vote(s) - 0 Average



Logout Mark Read Team Forum Stats Members Help
Memory leak in "save and restore" feature in "Retroplayer". Who can debug/fix this?00