Ocarina of Time: a NUP whose .zs textures have a zeroed head packs without any error, then the game slows down and crashes (3 files); suggest checking .zs at pack time #2326

What happened

Ocarina of Time (0400486024DEC000, v131072) built from a NUP slowed down progressively on a 16 GB M5 MacBook Air: 30 fps → ~8 fps after 6–10 minutes, with MapPhysicalMemory ... application pool is full and the loader thread OptimizeChangeBanc pinned. The log's DM_FSLOG showed one file, Tex/Rock_WaterTemple_Gate_M_01_Nrm.bntx.zs (452972 bytes), read 52,041 times in 599 s, in lockstep with the model Land_ZoraRiver_ConnectionGate_A_01.bfres.zs.

The cause: three .zs files in the NUP have their first 8–12 KB zeroed, so the zstd frame header and the first block are lost:

• Tex/CmnTex_Map_Soil_FairyFountain_Floor_D_Nrm.bntx.zs (216015 bytes)
• Tex/RBake_Scene_GanonStage_G_2_1_d0_t0.bntx.zs (1901341 bytes)
• Tex/Rock_WaterTemple_Gate_M_01_Nrm.bntx.zs (452972 bytes)

The NUP's per-file SHA-256 passes (the hash was taken over the damaged bytes), pack_nup.py packs it without a message, and a second download of the same NUP has the same three files. docs/reference/packing.md already says "A damaged file in a NUP or a dump has no hash to fail". Nothing in the build or at run time says which file is bad: the game retries the decode forever instead.

Suggestion

When pack_nup.py (and the dump path) reads each .zs, check that it starts with the zstd magic 28 b5 2f fd (or a skippable frame 50 2a 4d 18), and list the file names that do not, as the build already does for other damaged inputs. A file that is zero at the head is cheap to detect: a 16-byte read per .zs. I wrote a read-only scanner that does this against a built romfs.img and found exactly these three: https://github.com/qq3229311585-jpg/oot2-mac-notes (no game data in it).

Two things that may help others

• With the three files replaced by same-size stand-ins (valid zstd frame, same decompressed size; the BNTX's internal texture name must be rewritten to the target's name, and the relocation table _RLT must stay valid or the game crashes with a pointer that had the base added twice), the loop is gone: 95 segments / ~17 min at a flat 33.3 ms, GPU waits so far flat after updating to a build containing fd8188c9, resident memory ~6 GB instead of 12 GB with DM_GUEST_FILE=1.
• Related, already tracked: Ocarina of Time: GPU time per frame triples after a big scene change (leaving the Deku Tree) and stays up until restart (M2 Pro 16 GB) #2277 (slow motion after a large scene change), Ocarina of Time (Mac) - Flickering purple horizontal line follows the primary display #1821 (purple horizontal line; I see it too, rarely).

Environment

Game: The Legend of Zelda: Ocarina of Time (Switch 2), 0400486024DEC000, v131072. Mac app (--platform mac-app). MacBook Air, Apple M5, 16 GB, macOS 27.2. Seen on commit dbf8499 (shader chain eb68aba755a5); the slowdown with the allocator pool was gone on 01ec314 (chain b8856126d238). Settings: DM_FPS_TARGET=30, DM_OPMODE=1, DM_PRESENT_UPSCALE=metalfx, DM_GUEST_FILE=1.

I can attach the logs (no game files in them) if useful.

• Nothing attached here contains game files, keys or data extracted from a game.