MagicBeanDev/Hookshot

Archived

Watch

Fork 0

Linux, Intel Arc B390 (Mesa ANV 26.2.5): segfault in libvulkan_intel.so on the first task/mesh draw after loading a save #748

Closed

opened 2026-11-08 19:40:10 +00:00 by felipecsl · 4 comments

felipecsl commented

2026-11-08 19:40:10 +00:00

(Migrated from github.com)

Hookshot version

hookshot v2.0.2-19-g66892e6 (source acd3b3a0) — main at 66892e6, built as the Linux AppImage with scripts/linux/deps.sh + scripts/linux/appimage.sh in an ubuntu:22.04 container (same steps as CI), then --cli --update into the game folder.

What kind of problem

Crash, freeze or black screen

What happened

The game segfaults inside Mesa's Intel Vulkan driver (ANV) on the first task/mesh draw after loading a save. Shader preparation finished cleanly first (prepared 31985 shader programs (39842 new, 0 failed, 3808 stage libraries) in 652.8 s).

The crash is a read of address 0xc8 in libvulkan_intel.so+0x3a9b48, which looks like a NULL object plus an offset in the driver. It is called from an indirect call (call *(%rax), probably the Vulkan draw call) in mkwvk::draw, reached through replay ← run_submit ← submit_job ← submit_q. It happens on the same draw both times: program 1bae, 3 stages (stage 1 + task stage 6 + mesh stage 7), mesh draw kind 0: 0 12 512. The GPU reports mesh shaders yes, so this is the native mesh path, not the #640 compute fallback.

This build includes the overnight mesh changes (#640's emit_spirv_mesh.cpp / vk_draw.cpp changes) and the Intel changes (#496, #548). I have not bisected it yet. The vk back end can be rebuilt on its own, so I can test a hookshot_vk.so from a branch or commit if that helps.

Possibly related: #17 has a B390 report, but that one is a device lost on Windows, while this is a segfault in the driver on Linux.

Where in the game

Right after loading a save file, before the first in-game frame.

How often

Every time (2 of 2 runs, identical crash address and draw).

Graphics card and driver version

Intel Arc B390 (Panther Lake iGPU), Mesa vulkan-intel 26.2.5 (Arch; libvulkan_intel.so BuildID 6ce609c1a667be4f4358bbbbdc5dd02a7ad6a5dd), Vulkan 1.4, driver 0x6802005

CPU, RAM and operating system

Intel Core Ultra X7 358H, 32 GB, Arch Linux (Omarchy), kernel 7.2.15, Wayland (Hyprland)

Changes from the defaults

None (no hookshot_env.txt).

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

Excerpt below; full hookshot_log.txt and hookshot_log.1.txt attached.

[hos host] hookshot v2.0.2-19-g66892e6 (source acd3b3a0)
[hos host] vk: device 0: Intel(R) Arc(tm) B390 (PTL), Vulkan 1.4, driver 0x6802005, type 1
[hos host] vk: subgroups: default 32 lanes, 16-32, pinned to 32 on stages 0xe0
[hos host] vk: robust buffer access on
[hos host] vk: Intel(R) Arc(tm) B390 (PTL), Vulkan 1.4, driver 0x6802005; mesh shaders yes, host memory import yes, pipeline libraries yes
[hos host] vk: swapchain 1280x720, 4 images, mailbox
[hos host] vk: replay ready (window; push descriptors yes (32), extended dynamic state 3 yes, custom border colours yes)
[hos host] vk: pipeline cache /home/felipecsl/Games/Hookshot/mkw_vk_pipelines.bin (850907 KB)
[hos host] vk: program cache /home/felipecsl/Games/Hookshot/hookshot_programs.bin: 39857 program keys kept, 5653735 KB
...
[hos Presentation Thread] vk: mesh draw kind 0: 0 12 512, indirect 0 count 0 max 0 stride 0
[hos Presentation Thread] vk: mesh draw: program 1bae, 3 stages: [0: stage 1, code 0x7ffb252f00, sph type 5 bits24-25 0, isbe 0 payload 0] [1: stage 6, code 0x7ffae43c00, sph type 1 bits24-25 0, isbe 1 payload 256] [2: stage 7, code 0x7ffb256e00, sph type 3 bits24-25 2, isbe 1 payload 256]
[hos Presentation Thread] CRASH: exception 0xc0000005 (read 0xc8, guest 0xfffff000000000c8) at /usr/lib/libvulkan_intel.so+0x3a9b48
[hos Presentation Thread] CRASH: host backtrace: hookshot+0x62636f9 hookshot+0x1bfd62c1 libc.so.6+0x3e6f0 libvulkan_intel.so+0x3a9b48 libvulkan_intel.so+0x3abc35 libvulkan_intel.so+0x36f179 libvulkan_intel.so+0x37940c hookshot_vk.so+0x2cafed hookshot_vk.so+0x33fe27 hookshot_vk.so+0x33ba41 hookshot_vk.so+0x3396d5 hookshot_vk.so+0x3362e7 hookshot+0x1bfcb95d hookshot+0x2f5f55a hookshot+0x1bf98108 hookshot+0x1bf98108 hookshot+0x188eb6d hookshot+0x1bf98108 hookshot+0x188eff7 hookshot+0x1bf9e448 hookshot+0x1bfd149f libc.so.6+0x98042 libc.so.6+0x12072c
[hos Presentation Thread] CRASH: thread Presentation Thread, sp 0x10073c9f70
[hos Presentation Thread] CRASH: guest backtrace: lr 0x80590358 0x80df26c0 0x834a2ec8 0

Before you send it

I'm on the newest release, or the problem is still there on it. (main past v2.0.2)
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version `hookshot v2.0.2-19-g66892e6 (source acd3b3a0)` — `main` at 66892e6, built as the Linux AppImage with `scripts/linux/deps.sh` + `scripts/linux/appimage.sh` in an `ubuntu:22.04` container (same steps as CI), then `--cli --update` into the game folder. ### What kind of problem Crash, freeze or black screen ### What happened The game segfaults inside Mesa's Intel Vulkan driver (ANV) on the **first task/mesh draw** after loading a save. Shader preparation finished cleanly first (`prepared 31985 shader programs (39842 new, 0 failed, 3808 stage libraries) in 652.8 s`). The crash is a read of address `0xc8` in `libvulkan_intel.so+0x3a9b48`, which looks like a NULL object plus an offset in the driver. It is called from an indirect call (`call *(%rax)`, probably the Vulkan draw call) in `mkwvk::draw`, reached through `replay` ← `run_submit` ← `submit_job` ← `submit_q`. It happens on the same draw both times: program `1bae`, 3 stages (stage 1 + task stage 6 + mesh stage 7), `mesh draw kind 0: 0 12 512`. The GPU reports `mesh shaders yes`, so this is the native mesh path, not the #640 compute fallback. This build includes the overnight mesh changes (#640's `emit_spirv_mesh.cpp` / `vk_draw.cpp` changes) and the Intel changes (#496, #548). I have not bisected it yet. The vk back end can be rebuilt on its own, so I can test a `hookshot_vk.so` from a branch or commit if that helps. Possibly related: #17 has a B390 report, but that one is a device lost on Windows, while this is a segfault in the driver on Linux. ### Where in the game Right after loading a save file, before the first in-game frame. ### How often Every time (2 of 2 runs, identical crash address and draw). ### Graphics card and driver version Intel Arc B390 (Panther Lake iGPU), Mesa `vulkan-intel` 26.2.5 (Arch; `libvulkan_intel.so` BuildID `6ce609c1a667be4f4358bbbbdc5dd02a7ad6a5dd`), Vulkan 1.4, driver 0x6802005 ### CPU, RAM and operating system Intel Core Ultra X7 358H, 32 GB, Arch Linux (Omarchy), kernel 7.2.15, Wayland (Hyprland) ### Changes from the defaults None (no `hookshot_env.txt`). ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt Excerpt below; full `hookshot_log.txt` and `hookshot_log.1.txt` attached. ```text [hos host] hookshot v2.0.2-19-g66892e6 (source acd3b3a0) [hos host] vk: device 0: Intel(R) Arc(tm) B390 (PTL), Vulkan 1.4, driver 0x6802005, type 1 [hos host] vk: subgroups: default 32 lanes, 16-32, pinned to 32 on stages 0xe0 [hos host] vk: robust buffer access on [hos host] vk: Intel(R) Arc(tm) B390 (PTL), Vulkan 1.4, driver 0x6802005; mesh shaders yes, host memory import yes, pipeline libraries yes [hos host] vk: swapchain 1280x720, 4 images, mailbox [hos host] vk: replay ready (window; push descriptors yes (32), extended dynamic state 3 yes, custom border colours yes) [hos host] vk: pipeline cache /home/felipecsl/Games/Hookshot/mkw_vk_pipelines.bin (850907 KB) [hos host] vk: program cache /home/felipecsl/Games/Hookshot/hookshot_programs.bin: 39857 program keys kept, 5653735 KB ... [hos Presentation Thread] vk: mesh draw kind 0: 0 12 512, indirect 0 count 0 max 0 stride 0 [hos Presentation Thread] vk: mesh draw: program 1bae, 3 stages: [0: stage 1, code 0x7ffb252f00, sph type 5 bits24-25 0, isbe 0 payload 0] [1: stage 6, code 0x7ffae43c00, sph type 1 bits24-25 0, isbe 1 payload 256] [2: stage 7, code 0x7ffb256e00, sph type 3 bits24-25 2, isbe 1 payload 256] [hos Presentation Thread] CRASH: exception 0xc0000005 (read 0xc8, guest 0xfffff000000000c8) at /usr/lib/libvulkan_intel.so+0x3a9b48 [hos Presentation Thread] CRASH: host backtrace: hookshot+0x62636f9 hookshot+0x1bfd62c1 libc.so.6+0x3e6f0 libvulkan_intel.so+0x3a9b48 libvulkan_intel.so+0x3abc35 libvulkan_intel.so+0x36f179 libvulkan_intel.so+0x37940c hookshot_vk.so+0x2cafed hookshot_vk.so+0x33fe27 hookshot_vk.so+0x33ba41 hookshot_vk.so+0x3396d5 hookshot_vk.so+0x3362e7 hookshot+0x1bfcb95d hookshot+0x2f5f55a hookshot+0x1bf98108 hookshot+0x1bf98108 hookshot+0x188eb6d hookshot+0x1bf98108 hookshot+0x188eff7 hookshot+0x1bf9e448 hookshot+0x1bfd149f libc.so.6+0x98042 libc.so.6+0x12072c [hos Presentation Thread] CRASH: thread Presentation Thread, sp 0x10073c9f70 [hos Presentation Thread] CRASH: guest backtrace: lr 0x80590358 0x80df26c0 0x834a2ec8 0 ``` ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. (`main` past v2.0.2) - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

felipecsl commented

2026-11-09 02:38:48 +00:00

(Migrated from github.com)

Update, retested on main at b82bd36 (v2.0.5-19-gb82bd36). Same machine: Arc B390, Mesa ANV 26.2.5, Arch.

The original crash is gone. The first task/mesh draw (program 1bae) no longer crashes.

A new crash replaces it, every time (3 of 3 runs), in the loading screen after picking a save, before Link appears. It's a SIGSEGV in libvulkan_intel.so+0x9d8763, with a deep driver backtrace, on a background worker building a graphics pipeline:

[hos host] CRASH: exception 0xc0000005 (read 0x7ff0377c0b60, guest 0x6ff0377c0b60) at /usr/lib/libvulkan_intel.so+0x9d8763
host backtrace: ... libvulkan_intel.so+0x9d8763 +0x9d95c8 +0x9d9fa5 +0x97a801 +0x8dde40 +0x8df454 +0x74f14 +0x4fcba7 +0x4f84fd +0x4f89e6
  hookshot_vk.so: build_graphics <- graphics_pipeline()::$_0 <- worker (vk_jobs.cpp)

I added a log line before and after the guarded_graphics call in build_graphics. Exactly one pipeline started and never finished, and it was the same one in every run: program b0b3b40244c71ec7, a mesh + fragment pipeline (stages 0x80, 0x10). That's one of the grass-shadow programs that 674d6e1 (#482, "mesh programs with control topology 1 draw points") names. Its mesh SPIR-V has OutputPoints, PrimitivePointIndicesEXT and a PointSize output, LocalSize 32, OutputVertices 32 and OutputPrimitivesEXT 32. Both stages pass spirv-val --target-env vulkan1.3 --uniform-buffer-standard-layout --scalar-block-layout. So this looks like a Mesa ANV compiler bug with point-output mesh shaders that #482 now runs into. (I'm not attaching the SPIR-V, because it's built from the game's shaders. I can send the disassembly or anything else you need.)

Confirmed by undoing #482: with git revert 674d6e1 (only hookshot_vk.so rebuilt), the crash is gone and the save loads. But the picture is unplayable, with random shapes, objects and icons flashing all over the screen. That's more than the grass-shadow streaks #482 fixed, so it may be a separate Intel rendering problem. So reverting isn't a fix. Intel probably needs another way to draw these point meshes, for example as tiny triangles, or a fix in Mesa.

Also: with this build, the first-start shader preparation (after #772) needed about 33 GB (18 GB RSS + 14.5 GB swap). The previous build peaked around 20 GB. On a 32 GB machine it swapped for 20+ minutes. I skipped it with hookshot_prepare_skipped to get to the crash. I can open a separate issue for that if it's useful.

Update, retested on `main` at `b82bd36` (`v2.0.5-19-gb82bd36`). Same machine: Arc B390, Mesa ANV 26.2.5, Arch. **The original crash is gone.** The first task/mesh draw (program `1bae`) no longer crashes. **A new crash replaces it, every time (3 of 3 runs), in the loading screen after picking a save, before Link appears.** It's a SIGSEGV in `libvulkan_intel.so+0x9d8763`, with a deep driver backtrace, on a background worker building a graphics pipeline: ```text [hos host] CRASH: exception 0xc0000005 (read 0x7ff0377c0b60, guest 0x6ff0377c0b60) at /usr/lib/libvulkan_intel.so+0x9d8763 host backtrace: ... libvulkan_intel.so+0x9d8763 +0x9d95c8 +0x9d9fa5 +0x97a801 +0x8dde40 +0x8df454 +0x74f14 +0x4fcba7 +0x4f84fd +0x4f89e6 hookshot_vk.so: build_graphics <- graphics_pipeline()::$_0 <- worker (vk_jobs.cpp) ``` I added a log line before and after the `guarded_graphics` call in `build_graphics`. Exactly one pipeline started and never finished, and it was the same one in every run: **program `b0b3b40244c71ec7`**, a mesh + fragment pipeline (stages `0x80`, `0x10`). That's one of the grass-shadow programs that 674d6e1 (#482, "mesh programs with control topology 1 draw points") names. Its mesh SPIR-V has `OutputPoints`, `PrimitivePointIndicesEXT` and a `PointSize` output, `LocalSize 32`, `OutputVertices 32` and `OutputPrimitivesEXT 32`. Both stages pass `spirv-val --target-env vulkan1.3 --uniform-buffer-standard-layout --scalar-block-layout`. So this looks like a Mesa ANV compiler bug with point-output mesh shaders that #482 now runs into. (I'm not attaching the SPIR-V, because it's built from the game's shaders. I can send the disassembly or anything else you need.) **Confirmed by undoing #482:** with `git revert 674d6e1` (only `hookshot_vk.so` rebuilt), the crash is gone and the save loads. But the picture is unplayable, with random shapes, objects and icons flashing all over the screen. That's more than the grass-shadow streaks #482 fixed, so it may be a separate Intel rendering problem. So reverting isn't a fix. Intel probably needs another way to draw these point meshes, for example as tiny triangles, or a fix in Mesa. **Also:** with this build, the first-start shader preparation (after #772) needed about 33 GB (18 GB RSS + 14.5 GB swap). The previous build peaked around 20 GB. On a 32 GB machine it swapped for 20+ minutes. I skipped it with `hookshot_prepare_skipped` to get to the crash. I can open a separate issue for that if it's useful.

govt-boot-licker commented

2026-11-09 05:12:15 +00:00

(Migrated from github.com)

Let me guess, Intel G3 extreme handheld ?

felipecsl commented

2026-11-09 05:15:04 +00:00

(Migrated from github.com)

no, intel arc B390 (dell xps 14)

NotRexed commented

2026-11-09 05:55:32 +00:00

(Migrated from github.com)

Tracked in #999, follow there. That issue collects every report of Intel Arc / Core Ultra device lost, black screens and Linux ANV crashes, and this one is linked from it with its GPU, version and log details. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your hookshot_log.txt.

Commenting is not possible because the repository is archived.