Well, I was hunting down a folder navigation memory leak and managed to get clover-kmod to go into freespin in kernel-land (looks like a bad mutex on a Linux API call) instead - it's taking up an entire CPU and the on-TV UI is completely hung (but did not crash out to a c8).
So far, it definitely appears there is a memory leak triggered by folder navigation, completely independent of Kachikachi or Retroarch...it's the UI itself (because, of course, there is no concept of 'folders' in the unhacked UI).
More soon...
Rodney
EDIT: I tried killing off clover-mcp, and was successful, system stayed up with no Nintendo code running. Issued a reboot via terminal, and sure enough, triggered a C2. There is absolutely a relationship between a UI memory leak (likely in ReedPlayer-Clover, which died before clover-mcp and hung the TV display), folder navigation, and the C2.
EDIT2: Bingo! When clover-mcp normally terminates, it must write some sort of check file. If you kill it manually, then reboot, you C2 every time. The Linux OOM killer is taking it out at some point, which triggers the C8, then the C2.
EDIT3: Same thing happens if you kill ReedPlayer-Clover then reboot.
EDIT4: clover-mcp is responsible for the "SHUTTING DOWN" message on reboot...if you kill it, no message. Not sure whether it's ReedPlayer-Clover or clover-mcp that's doing the checkpoint, because killing off either definitely triggers a C2 on restart. I can at least say with some confidence that the fears about droplets being left behind by the RetroArch emulators is unfounded...at least with FCEUMM, you can clearly see the filesystem is quite stable between starts (tested with ~70 attempts in one session).
Unfortunately, until I can cross-compile some debugging tools for this, it's going to be hard to track down any further. Sadly, it would seem very likely at this point that the memory leak is just a knock-on effect of the way the UI is 'manipulated' to achieve folders, being a bug in Nintendo code we have no source to and thus there's nothing that can be effectively done about it. It *might* be possible to reload ReedPlayer-Clover occasionally to mitigate this...we'll see.
EDIT5: Hrm. Any coders have a clue why this would be? It would seem ReedPlayer-Clover *can't* be reloaded, because it's missing a Locale function...but then how the hell does it run to begin with? Some missing environment variable?
Code:
root@CLOVER:~# ReedPlayer-Clover --bootapp=/usr/share/clover-ui --script VOLATILE_SUSPENSION_POINTS_PATH='/var/cache/clover//volatile/' --script PERSISTENT_SUSPENSION_POINTS_PATH='/var/lib/clover/profiles/0/' --script-file /usr/share/legal/licenses.lua --script-file /var/cache/clover//menu.lua --language=en --region=USA
ReedPlayer-Clover --bootapp=/usr/share/clover-ui --script VOLATIL
E_SUSPENSION_POINTS_PATH='/var/cache/clover//volatile/' --script PERSISTENT_SUSP
ENSION_POINTS_PATH='/var/lib/clover/profiles/0/' --script-file /usr/share/legal/
licenses.lua --script-file /var/cache/clover//menu.lua --language=en --region=US
A
Core needs an UTF-8 C locale, we set it to "en_US.UTF-8" instead of "C".
This is a global side-effect and is subject to change, please don't rely on this.
updated hinting sdl game controller
added hinting sdl game controller
added hinting sdl game controller
loaded 44 mappings from /etc/sdl2/gamecontrollerdb.txt
Unimplemented function: 'getUserLocale'!
File: '/home/cis/workspace/Clover-release/dd017d64/output/clover-dp-nes-final/build/nerd-reed-libs-f2d9a762fcd927fcee03a0de68d2cadfad21df45/src/reedframework/localization/reed_localization.cpp'
Line: 169
ReedPlayer: Main exited
