Emulator

EDIT:
What steps will reproduce the problem?

Start the wii menu and change disc on Dolphin 4.0-8012 or newer

This is the same sort of problem I was having. - https://bugs.dolphin-emu.org/issues/9046

I was able to reproduce the steps, but made Dolphin crash instead when selecting a WiiWare title. I will have to try with the Internet Channel to see if the same result happens or not.

Anyways, the crash seems to happen once it hits IOFile::Seek. That's about as far I got yesterday, but perhaps someone could look into it from there.

Doing some more debugging, it either crashes in one of two spots:

https://github.com/dolphin-emu/dolphin/blob/1b69743ba14ebca7c51862b7df8da6751eb213f0/Source/Core/Core/IPC_HLE/WII_IPC_HLE_Device_es.cpp#L423

or

https://github.com/dolphin-emu/dolphin/blob/1b69743ba14ebca7c51862b7df8da6751eb213f0/Source/Core/Core/IPC_HLE/WII_IPC_HLE_Device_es.cpp#L410

Still trying to debug this further

I can reproduce this on 450P (should be 4.1 Europe) when right-clicking a game, then selecting "Change Disc".
However, for me Dolphin crashes as a whole instead of showing the "system files are corrupt" message.

m_data is not empty(), as the check indicates, so it does the memcpy. Which looks like a bad idea from there:
m_data = { size=1125917086973956 }

Reverting the unique_ptr part of c22d1d6 (which sadly wasn't its own commit =/) fixes the issue. I suspect something is going out of scope, causing the CNANDContentLoader to be free'd while we still want to use it.

Commenting out this call to CNANDContentManager::ClearCache fixes the crash, but thats rather random to simply remove it (I hope @comex had a reason to put it there).
When changing disc, it is being called twice (before the banner changes to the inserted disc), causing those accesses to get free'd memory instead.
CWII_IPC_HLE_Device_es::OpenInternal is breaking the tracking capabilities of unique_ptr, since we store the raw pointer there, with a different life time than the map in CNANDContentManager.

Since I don't want this to get lost, dumping it on here:

-19:59:14- [Fog_TAS] as for that clearcache line
-19:59:46- [Fog_TAS] CNANDContentLoader reads title.tmd and caches data from it, ES_DIVerify writes to title.tmd
-20:00:02- [Fog_TAS] paraphrasing here

So: clearing the cache on DI_Verify makes sense, altho the side-effect of things crashing isn't necessarily what we want.

About the else of that block (with the failing memcpy):

-20:05:01- [comex] ok, let me actually look at this code properly
-20:05:16- [comex] you probably found it, but the commit was 04c41c1d3
-20:06:07- [comex] oh, i see, it's for wads
-20:06:21- [comex] specifically, loading them without extracting them first
-20:06:27- [comex] look at CNANDContentLoader::InitializeContentEntries
-20:07:19- [comex] the code seems wrong if the content is actually empty (0 bytes) though

So, it is likely that we still need that else, but exploding on clear (due to accessing of free'd memory) combined with the last mention (it being wrong for empty contents; regardless of whether that can ever be) strongly suggests we should think this over.

If I had to write up some sort of plan, I'd first try to get rid of the m_pContentLoader reference (and along that, the m_NANDContent cache that has its redundancy note above CWII_IPC_HLE_Device_es::AccessContentDevice for quite some time). As requirement for that, SContentAccess.m_pContent needs to go too, with some replacement for m_Size/m_Index (which are state-saved) and m_Data (which is the key in all this). The latter is responsible for the crashes we see in here, and the tricky part is loading it at the right time while keeping it in memory unnecessarily.
Perhaps CNANDContentLoader::InitializeContentEntries can be delayed and/or in-time resolved when this sort of access happens, or be wrapped in something like IOFile so we don't have to distinguish this case.