[lunks]

What and why

Ocarina of Time (Switch 2, 0400486024DEC000) can pass a NULL memory pool to nvnBufferInitialize on entering Hyrule Field, about 1.5 minutes after a save load (#1445):

[RED] BufferInitialize: pool has no storage (pool 0x0 flags 0 offset 0 size 0x3d0)
CRASH sig=11 addr=0x4 pc=h_nvnMemoryPoolGetFlags+0

The host then crashes reading the pool in the next getter. The eight getters (nvnMemoryPoolGetFlags, nvnMemoryPoolMap, nvnMemoryPoolGetSize, nvnBufferGetAddress, nvnBufferMap, nvnBufferGetSize, nvnBufferGetMemoryPool, nvnBufferGetMemoryOffset) now answer 0 or NULL for a null pool or buffer.

This only moves the failure. What made the game's allocator return no pool is not known. The host-side log shows no refused allocation or pool failure before it; the numbers at the crash (from #1445's log): heap 6.20 GB, alias region 16 GB with 5.25 GB mapped, 5,061 memory pools, 11.3 GB GPU allocated. The existing reference entry for the same two log lines (Model heaps sized by the host's command record sizes) is another candidate, and it now notes this case.

The change is the hle_nvn.c part of #1444 (ksolenk38ze), taken alone so it can land without the rest; the commit keeps their authorship.

Checked

• Tests: make -C dm/host GAME=040074A01BF12000 builds; test_docs.py and docs_symptoms.py --check pass. No unit test: the getters are one-line guards.
• Games run: none. The crash is Ocarina of Time (0400486024DEC000 v131072, Mac): entering Hyrule Field, nvnBufferInitialize gets a NULL memory pool and the host crashes in nvnMemoryPoolGetFlags #1445's report; not reproduced here.
• Devices and OS: M5 Pro, macOS 26.

Docs

• The finding is in its game note or its docs/reference/<subsystem>.md entry, and python3 dm/tools/docs_symptoms.py was run (the symptom index)
• No game files, keys or data extracted from a game in the change or the attachments

[seedds]

Thanks for splitting this out of #1444. I'm closing it without landing, because it hides the crash rather than fixing it.

• NVN doesn't check either. The driver's pool and buffer getters don't null-check their argument, and the host currently matches that. In v131072, main+0x8e5130 creates a buffer from the game's own allocation record (pool at record +0x10, size from src+0x120). It doesn't check nvnBufferInitialize's result and calls nvnMemoryPoolGetFlags on the same pool right after. A null pool there would crash on console too, so the game never gets there with one on console. The null pool is the divergence to find.
• It moves the failure into game code. nvnBufferInitialize returns before writing the buffer, so with the guards the game carries on with a buffer that was never set up. nvnBufferMap answers NULL and the next write goes through NULL in game code. That crash would tell us less than the current one, which names the null pool.
• No measured benefit. The crash wasn't reproduced and no run shows the game going on afterwards.
• The docs line. It adds an unconfirmed case to the "Model heaps sized by the host's command record sizes" entry. An open crash with an unknown cause belongs in the game's note, marked open.

The cause is tracked in #1445: why that record has no pool.