[Crash] Kakariko Village day-to-night transition: null memory pool in OptimizeChangeBanc (guest 0x4) #509

Closed
opened 2026-11-08 07:24:27 +00:00 by nicholasgower · 1 comment
nicholasgower commented 2026-11-08 07:24:27 +00:00 (Migrated from github.com)

Related: #287 is the existing tracker for this null-memory-pool crash in OptimizeChangeBanc (guest 0x4). 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) (the foliage-linux-updater build). The log says the latest release is compile-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 OptimizeChangeBanc thread. 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 no hookshot_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 exact hookshot_log.txt from 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.txt

Crash:

[hos OptimizeChangeBanc] CRASH: exception 0xc0000005 (read 0x100000000004, guest 0x4) at hookshot.exe+0x1a53b5dd
[hos OptimizeChangeBanc] CRASH: thread OptimizeChangeBanc, sp 0x105a69eae0
[hos OptimizeChangeBanc] CRASH:   x0  0000000000000000  x1  000000105a69eae0  x2  0000000000000000  x3  00000000000003d0
[hos OptimizeChangeBanc] CRASH:   x19 0000007e7bb12f20  x20 0000000000000000  x21 0000007e7baf7c90  x22 000000105a69eb60
[hos OptimizeChangeBanc] CRASH:   x29 000000105a69eb20  x30 00000000809051ec
[hos OptimizeChangeBanc] CRASH: guest backtrace: lr 0x809051ec 0x814f2a3c 0x800ac780 0x800ac614 0x80456fb4 0x80455a70 0x83bb5a14 ...

Analysis from the log: The host offset hookshot.exe+0x1a53b5dd is n_nvnMemoryPoolGetFlags+0xd. It reads the pool's flags at +4, with x0 = 0. The guest caller is the texture-building helper f_80905130: it builds a texture on the stack, passes the pool pointer [x21] to the storage setter and to nvnTextureInitialize (which already handles a null pool), then calls nvnMemoryPoolGetFlags with the same [x21] = 0. So this is a texture with no storage pool being prepared during the banc change. P(0) returns NULL for a zero argument, but ((nvn_pool *)NULL)->flags is undefined behaviour and was compiled as a read at A64_MEM + 4. The texture-builder queries got the no_builder guard 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.

**Related:** #287 is the existing tracker for this null-memory-pool crash in `OptimizeChangeBanc` (guest `0x4`). 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)` (the `foliage-linux-updater` build). The log says the latest release is `compile-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 `OptimizeChangeBanc` thread. 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 no `hookshot_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`)](https://gist.github.com/nicholasgower/4e8f3fca69a1581a54dd13d44ff66b1d) — this is the exact `hookshot_log.txt` from 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.txt **Crash:** ``` [hos OptimizeChangeBanc] CRASH: exception 0xc0000005 (read 0x100000000004, guest 0x4) at hookshot.exe+0x1a53b5dd [hos OptimizeChangeBanc] CRASH: thread OptimizeChangeBanc, sp 0x105a69eae0 [hos OptimizeChangeBanc] CRASH: x0 0000000000000000 x1 000000105a69eae0 x2 0000000000000000 x3 00000000000003d0 [hos OptimizeChangeBanc] CRASH: x19 0000007e7bb12f20 x20 0000000000000000 x21 0000007e7baf7c90 x22 000000105a69eb60 [hos OptimizeChangeBanc] CRASH: x29 000000105a69eb20 x30 00000000809051ec [hos OptimizeChangeBanc] CRASH: guest backtrace: lr 0x809051ec 0x814f2a3c 0x800ac780 0x800ac614 0x80456fb4 0x80455a70 0x83bb5a14 ... ``` **Analysis from the log:** The host offset `hookshot.exe+0x1a53b5dd` is `n_nvnMemoryPoolGetFlags+0xd`. It reads the pool's `flags` at `+4`, with `x0 = 0`. The guest caller is the texture-building helper `f_80905130`: it builds a texture on the stack, passes the pool pointer `[x21]` to the storage setter and to `nvnTextureInitialize` (which already handles a null pool), then calls `nvnMemoryPoolGetFlags` with the same `[x21] = 0`. So this is a texture with no storage pool being prepared during the banc change. `P(0)` returns `NULL` for a zero argument, but `((nvn_pool *)NULL)->flags` is undefined behaviour and was compiled as a read at `A64_MEM + 4`. The texture-builder queries got the `no_builder` guard 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.
nicholasgower commented 2026-11-08 07:25:22 +00:00 (Migrated from github.com)

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.

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.
Commenting is not possible because the repository is archived.
No milestone
No assignees
1 participant
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Hookshot#509
No description provided.