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
This appears to be a missing function 'getUserLocale' which would return the UTF-8 C locale according to the code.
the "volatile" variables would be system-wide variables that would be accessible by reading from the main memory.
As for the memory issue, it's possible that Nintendo just used the reset system to clear the memory since there were only 30 games stored. The way the
folders act is similar in regards to how games are loaded into memory. Thus taking up precious space. It would appear Nintendo never anticipated this many games (or folders)
and by design just had the NES Classic clear the RAM/cache when you turn the system off.
Once Cluster has access to the "live" library this should hopefully shed some light on the subject and what can possibly be done to clear this (thus fixing the problem).
The other idea is to dump the stack when you power off the NES classic. To see if any system methods get called that could lead to a simulation of clearing the memory.