[Crash] Kakariko Village day-to-night transition: null memory pool in OptimizeChangeBanc (guest 0x4) #509
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#509
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Related: #287 is the existing tracker for this null-memory-pool crash in
OptimizeChangeBanc(guest0x4). This is the Kakariko Village day-to-night occurrence, with its own log; the root cause is the same, but the location and transition are different. A fix PR follows.Hookshot version:
hookshot 4d7d2f1 (source 7c11b60f)(thefoliage-linux-updaterbuild). The log says the latest release iscompile-retry.What kind of problem: Crash, freeze or black screen
What happened: I was walking around Kakariko Village as the time changed from day to night. The game closed instantly, with no Vulkan device-lost message. The log's last line before the crash is on the
OptimizeChangeBancthread. The session had run for about 30 minutes (71,040 presents, 36-40 fps).Where: Kakariko Village, inside the village, as the day-to-night transition began. Not entering or leaving Kakariko, and not a cutscene.
How often: Once so far. The latest save (
slot_01) was written at 10:46, about 80 seconds before the 10:47 crash, so reloading it and waiting for the transition should reproduce it.PC: NVIDIA GeForce RTX 3080, Vulkan 1.4, driver
0x93d58000; Intel UHD Graphics 770 is also present. The CPU and RAM are not recorded in the log. Working set 18.4 GB (peak 20.0 GB). Windows.Changes from the defaults:
hookshot_options.ini:quality_preset=3,fullscreen=0,frame_generation=2,frame_pacing=1,resolution=1,upscaling=1,sharpness=25,game_speed=1,handheld_profile=0,ultrawide=0,fps_counter=1,controller_in_background=1,text_speed=0. There is nohookshot_env.txt.Other software hooked into the game: None. There is no
hookshot_env.txt, and no overlay or injector appears in the log.hookshot_log.txt: Full log (3.1 MB, sha256
fc7d563e3caaa569054e1ec238684cc431f2359142d5073e1b47a610e57b641e) — this is the exacthookshot_log.txtfrom the crash. GitHub's attachment API only accepts images, so the full text file is in the gist rather than attached directly. Raw download: https://gist.githubusercontent.com/nicholasgower/4e8f3fca69a1581a54dd13d44ff66b1d/raw/948e8ddb487493e77d71026371b5689d58c19d89/hookshot_log.txtCrash:
Analysis from the log: The host offset
hookshot.exe+0x1a53b5ddisn_nvnMemoryPoolGetFlags+0xd. It reads the pool'sflagsat+4, withx0 = 0. The guest caller is the texture-building helperf_80905130: it builds a texture on the stack, passes the pool pointer[x21]to the storage setter and tonvnTextureInitialize(which already handles a null pool), then callsnvnMemoryPoolGetFlagswith the same[x21] = 0. So this is a texture with no storage pool being prepared during the banc change.P(0)returnsNULLfor a zero argument, but((nvn_pool *)NULL)->flagsis undefined behaviour and was compiled as a read atA64_MEM + 4. The texture-builder queries got theno_builderguard in #284/#287; the memory-pool getters did not.Expected: The day-to-night transition should complete. A null pool should answer
0, as the no-builder queries do, rather than crash.Opened #510 with the fix:
o_pool()\ guards the memory-pool accessors (GetFlags, GetSize, GetBufferAddress, Map, etc.) before dereferencing a null pool, plus a game-free regression test. The null getters answer 0, like the
o_builder\ fix in #284/#287.