Ok I was able to work with Gemini Pro and it was able to find the possible cause and a possible fix. At least the workaround it suggested works and after that I can now login to the new profile. Here is the issue report:
Issue: [RK3566] Kodi 22 Alpha3 Segfault on Profile Switch (SQLITE_MISUSE in CTextureDatabase) on Clean Install
Environment:
Hardware: Pine64 Quartz64 Model A
OS: LibreELEC (chewitt) 12.90.1 13.0
Kernel: Linux ARM 64-bit version 7.0.0
Kodi Version: 22.0-ALPHA3 (21.90.703)
Description:
Kodi suffers a hard segmentation fault when attempting to switch to a newly created profile. This occurs on a completely clean, default installation with no third-party add-ons or custom skins installed.
When switching to the new profile, Kodi appears to fail to cleanly release or establish locks on the core .db files. The new profile attempts to initialize and cache UI textures, receives an SQLITE_MISUSE (unable to open database file) error, and immediately segfaults while attempting to log the error via dbiplus::DbErrors.
Subsequent attempts to log into the new profile result in a continuous crash loop because the profile's Textures14.db and Thumbnails directory are left in a corrupted/incomplete state from the initial crash.
Steps to Reproduce:
Start with a fresh, default installation of LibreELEC.
Go to Settings > Profiles and create a new user profile.
Attempt to switch to or log into the newly created profile.
Kodi immediately crashes (Segmentation fault).
Kodi is restarted by systemd, but selecting the new profile on the login screen results in an immediate segfault every time.
Workaround:
Stopping the kodi service via SSH, deleting /storage/.kodi/userdata/Database/Textures14.db, and wiping the /storage/.kodi/userdata/Thumbnails/ directory resolves the crash loop and allows the new profile to initialize successfully on the next boot.
GDB Stack Trace (from kodi_crashlog):
Thread 1 (Thread 0xffff2f7eee20 (LWP 1181)):
#0 0x0000ffff8b1a3788 in ?? () from /usr/lib/libc.so.6
#1 0x0000ffff8b160c3c in ?? () from /usr/lib/libc.so.6
#2 0x0000ffff8b1806b0 in vsnprintf () from /usr/lib/libc.so.6
#3 0x0000000000dcb480 in dbiplus::DbErrors::DbErrors(char const*, ...) ()
#4 0x0000000000de1ce8 in dbiplus::SqliteDataset::exec(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#5 0x0000000000f7df60 in CTextureDatabase::AddCachedTexture(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, CTextureDetails const&) ()
#6 0x0000000000f7e2f8 in CTextureCache::OnCachingComplete(bool, CTextureCacheJob*) ()
#7 0x0000000000f7e478 in CTextureCache::OnJobComplete(unsigned int, bool, CJob*) ()
#8 0x0000000000c837d0 in CJobManager::OnJobComplete(bool, CJob*) ()
#9 0x0000000000c83c74 in ?? ()
#10 0x0000000000c37704 in CThread::Action() ()
Display More
Possible Fix:
Looking at the GDB stack trace, this appears to be a two-part issue tied to the profile teardown/startup sequence:
- The Root Cause (Race Condition): It seems CJobManager is not fully halting background tasks (specifically CTextureCacheJob) before the profile switch de-initializes the database connections. The background thread attempts to call CTextureDatabase::AddCachedTexture on a database connection that is either closed or in the process of being moved, resulting in the SQLITE_MISUSE error.
- The Segfault (Invalid Pointer in Logger): When dbiplus::SqliteDataset::exec catches the misuse error, it attempts to log it via dbiplus::DbErrors::DbErrors. The segfault inside vsnprintf suggests it is being passed a NULL pointer or an invalid memory address for the error string, crashing the application entirely rather than just logging the DB failure.
Ensuring the cache jobs are blocked/flushed before database teardown, and sanitizing the DbErrors string arguments, should resolve the crash.
Seems to not be able to create the nat chain in iptables, at least is a different error haha