MagicBeanDev/Hookshot

Archived

Watch

Fork 0

CRASH Mesa 26.2.6 Linux with v2.0.5 [regression] #803

Closed

opened 2026-11-08 21:58:22 +00:00 by mrdev023 · 7 comments

mrdev023 commented

2026-11-08 21:58:22 +00:00

(Migrated from github.com)

Hookshot version

v2.0.5

What kind of problem

Crash, freeze or black screen

What happened

Operating System: NixOS 26.11
KDE Plasma Version: 6.8.2
KDE Frameworks Version: 6.31.0
Qt Version: 6.12.0
Kernel Version: 7.3.1 (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 9950X3D 16-Core Processor
Memory: 128 Gio of RAM (123.4 Gio usable)
Graphics Processor 1: AMD Radeon RX 9070 XT
Graphics Processor 2: AMD Ryzen 9 9950X3D 16-Core Processor
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: X870E AORUS ELITE WIFI7
System Version: Default string-CF-WCP-ADO

Where in the game

Initial Startup

How often

Every time

Graphics card and driver version

RX 9070XT

CPU, RAM and operating system

AMD Ryzen 9 9950X3D, 128GB, Linux

Changes from the defaults

No response

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

Screenshots or video

No response

Before you send it

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

### Hookshot version v2.0.5 ### What kind of problem Crash, freeze or black screen ### What happened Operating System: NixOS 26.11 KDE Plasma Version: 6.8.2 KDE Frameworks Version: 6.31.0 Qt Version: 6.12.0 Kernel Version: 7.3.1 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 9950X3D 16-Core Processor Memory: 128 Gio of RAM (123.4 Gio usable) Graphics Processor 1: AMD Radeon RX 9070 XT Graphics Processor 2: AMD Ryzen 9 9950X3D 16-Core Processor Manufacturer: Gigabyte Technology Co., Ltd. Product Name: X870E AORUS ELITE WIFI7 System Version: Default string-CF-WCP-ADO ### Where in the game Initial Startup ### How often Every time ### Graphics card and driver version RX 9070XT ### CPU, RAM and operating system AMD Ryzen 9 9950X3D, 128GB, Linux ### Changes from the defaults _No response_ ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log.txt](https://github.com/user-attachments/files/34556017/hookshot_log.txt) ### Screenshots or video _No response_ ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

mrdev023 commented

2026-11-08 22:01:45 +00:00

(Migrated from github.com)

Another notes: Tried to remove completly the folder ~/Games/Hookshot/ and rebuild from scratch same problem

Another notes: Tried to remove completly the folder `~/Games/Hookshot/` and rebuild from scratch same problem

viktorsparda commented

2026-11-08 22:08:20 +00:00

(Migrated from github.com)

Same here
9070xt
ryzen 5 7600x
32gb
latest bazzite build

hookshot_log.txt

Same here 9070xt ryzen 5 7600x 32gb latest bazzite build [hookshot_log.txt](https://github.com/user-attachments/files/34556203/hookshot_log.txt)

emarleau commented

2026-11-08 22:09:17 +00:00

(Migrated from github.com)

I'm having the same problem as well

Arch Linux
Ryzen 5 5600X
Radeon RX9070XT
32gb RAM

I'm having the same problem as well Arch Linux Ryzen 5 5600X Radeon RX9070XT 32gb RAM

bbabnikk commented

2026-11-08 22:21:44 +00:00

(Migrated from github.com)

Same here, Oddly one launch succeeded, colors were washed out in game though.

Arch(Cachyos)
Ryzen 5800x3d
Radeon 7900xtx
32GB Ram.

Same here, Oddly one launch succeeded, colors were washed out in game though. Arch(Cachyos) Ryzen 5800x3d Radeon 7900xtx 32GB Ram.

phendriksnl commented

2026-11-09 01:28:10 +00:00

(Migrated from github.com)

Same crash here, and it is not limited to Mesa 26.2.6 — plus I found a workaround and what looks like the exact cause.

System


Hookshot	v2.0.5 (source c5895377), Linux AppImage
OS	SteamOS 3.9.5 (holo), kernel 7.2.7-valve2
GPU	AMD Steam Machine / RADV NAVI33 (`0x7481`), Vulkan 1.4
Mesa	26.1.2 (26.1.2.221562.radeonsi_26.1.2-2.1), not 26.2.6
Where	first start, during the shader preparation
How often	every start that attempts the preparation

Crash

CRASH: exception 0xc0000005 (write 0x40, guest 0xfffff00000000040) at /usr/lib/libvulkan_radeon.so+0x14d5bf
CRASH: host backtrace: hookshot+0x62658b9 hookshot+0x1bfb0511 libc.so.6+0x3e270 libvulkan_radeon.so+0x14d5bf
  libvulkan_radeon.so+0x12aa85 libvulkan_radeon.so+0x12b0b6 libvulkan_radeon.so+0x12b35a libvulkan_radeon.so+0x12b59b
  libVkLayer_steam_fossilize.so+0xd6ff3 hookshot_vk.so+0x30e32d hookshot_vk.so+0x4631e3 libc.so.6+0x97739 libc.so.6+0x11bedc

Same write 0x40 as the reported abort; the offset differs (0x14d5bf here vs 0x19be92/0x15b67d on 26.2.6), which is just where RADV dereferences the NULL in this Mesa build. Where it lands in the run:

vk: program cache /home/deck/Games/Hookshot/hookshot_programs.bin: 46502 program keys kept, 6521705 KB
vk: prepared 38809 shader programs (0 new, 165 failed, ...) in 23.7 s
vk: predicted 6019 pipelines from 14 notes for 6019 program variants ... 6019 made in 9.6 s
vk: the last start did not get through the precompile (closed, or it crashed there): trying it once more
CRASH: exception 0xc0000005 (write 0x40, ...) at libvulkan_radeon.so+0x14d5bf

The layer is not the cause

The crash backtrace contains libVkLayer_steam_fossilize.so, which is easy to chase. I turned that layer off for this game only, verified with VK_LOADER_DEBUG=layer that it is then genuinely not inserted (and grep -c fossilize /proc/<pid>/maps → 0), and it still crashed on the same offset. So that layer is a witness here, not the culprit.

This looks like the cause in #894

As #894 describes it: a compute variant that samples a depth-compared texture with an integer sampled type makes spirv_to_nir return NULL and RADV dereferences it. On this machine that is exactly what happens. With the preparation forced on and Mesa asked to dump what it rejects:

$ MESA_SPIRV_FAIL_DUMP_PATH=/tmp/spirv-dump ...   # then the game starts
$ ls /tmp/spirv-dump
0xfail.comp

$ spirv-val /tmp/spirv-dump/0xfail.comp
error: line 5052: Expected Image 'Sampled Type' to be the same as Result Type
  %3302 = OpImageSampleDrefExplicitLod %f32 %3301 %3300 %3281 Lod %f32_0

$ spirv-dis /tmp/spirv-dump/0xfail.comp | grep 'OpTypeImage %u'
%119 = OpTypeImage %u32 2D 1 1 0 1 Unknown

One rejected module out of 38,809 — a depth-compared image (2D 1) with an integer sampled type (%u32), sampled by OpImageSampleDrefExplicitLod at line 5052, and spirv-val rejects precisely that instruction. That is #894's variant, and the variant is in hookshot_programs.bin (the log says 0 new, 0 compute variants, so it is already cached), so it gets compiled again on every later start — which is also what #894 says.

I have not sent the dumped module: it is built from game shaders. The spirv-val line above is the whole of what it says.

Workaround

RX_VK_PRECOMPILE=0 in hookshot_env.txt, which skips the preparation. Tested in a nested Gamescope with WAYLAND_DISPLAY=gamescope-0 (so the Gamescope-WSI layer is on, as in Game Mode) and with ENABLE_VK_LAYER_VALVE_steam_fossilize_1=1 as Steam sets it:

run	preparation	result
1	left out	ok, 17,640 presents, 60 fps, ~4.5 min
2	attempted	crash, same offset
3	`RX_VK_PRECOMPILE=0`	ok, 11,520 presents, 60 fps, ~3.4 min
4	control, no switch	crash, same offset
5	`RX_VK_PRECOMPILE=0`	ok, 11,520 presents, 60 fps, ~3.4 min
6	via `hookshot_env.txt` only	ok, 11,760 presents, 60 fps, ~3.4 min

Run 6 is the same setup as run 2, with only that file added, so the file is being read and it is what makes the difference. The cost is stutter when a scene is seen for the first time, since the shaders are then compiled during play.

For those on Mesa 26.2.6

This issue mentions 26.2.6 specifically, but here it is 26.1.2 — so it is not a 26.2.6 regression, and the reported variants are the same thing. #894 and #834 (both open) look like the fixes.

I have the full hookshot_log.txt from the run above (183 lines); say the word and I will paste it or send it. I left out the dumped module on purpose, since it is built from game shaders.

Same crash here, and it is **not limited to Mesa 26.2.6** — plus I found a workaround and what looks like the exact cause. ### System | | | |---|---| | Hookshot | v2.0.5 (source c5895377), Linux AppImage | | OS | SteamOS 3.9.5 (holo), kernel 7.2.7-valve2 | | GPU | AMD Steam Machine / RADV NAVI33 (`0x7481`), Vulkan 1.4 | | Mesa | **26.1.2** (26.1.2.221562.radeonsi_26.1.2-2.1), not 26.2.6 | | Where | first start, during the shader preparation | | How often | every start that attempts the preparation | ### Crash ``` CRASH: exception 0xc0000005 (write 0x40, guest 0xfffff00000000040) at /usr/lib/libvulkan_radeon.so+0x14d5bf CRASH: host backtrace: hookshot+0x62658b9 hookshot+0x1bfb0511 libc.so.6+0x3e270 libvulkan_radeon.so+0x14d5bf libvulkan_radeon.so+0x12aa85 libvulkan_radeon.so+0x12b0b6 libvulkan_radeon.so+0x12b35a libvulkan_radeon.so+0x12b59b libVkLayer_steam_fossilize.so+0xd6ff3 hookshot_vk.so+0x30e32d hookshot_vk.so+0x4631e3 libc.so.6+0x97739 libc.so.6+0x11bedc ``` Same `write 0x40` as the reported abort; the offset differs (`0x14d5bf` here vs `0x19be92`/`0x15b67d` on 26.2.6), which is just where RADV dereferences the NULL in this Mesa build. Where it lands in the run: ``` vk: program cache /home/deck/Games/Hookshot/hookshot_programs.bin: 46502 program keys kept, 6521705 KB vk: prepared 38809 shader programs (0 new, 165 failed, ...) in 23.7 s vk: predicted 6019 pipelines from 14 notes for 6019 program variants ... 6019 made in 9.6 s vk: the last start did not get through the precompile (closed, or it crashed there): trying it once more CRASH: exception 0xc0000005 (write 0x40, ...) at libvulkan_radeon.so+0x14d5bf ``` ### The layer is not the cause The crash backtrace contains `libVkLayer_steam_fossilize.so`, which is easy to chase. I turned that layer off for this game only, verified with `VK_LOADER_DEBUG=layer` that it is then genuinely not inserted (and `grep -c fossilize /proc/<pid>/maps` → 0), and **it still crashed on the same offset**. So that layer is a witness here, not the culprit. ### This looks like the cause in #894 As #894 describes it: a compute variant that samples a depth-compared texture with an *integer* sampled type makes `spirv_to_nir` return NULL and RADV dereferences it. On this machine that is exactly what happens. With the preparation forced on and Mesa asked to dump what it rejects: ``` $ MESA_SPIRV_FAIL_DUMP_PATH=/tmp/spirv-dump ... # then the game starts $ ls /tmp/spirv-dump 0xfail.comp $ spirv-val /tmp/spirv-dump/0xfail.comp error: line 5052: Expected Image 'Sampled Type' to be the same as Result Type %3302 = OpImageSampleDrefExplicitLod %f32 %3301 %3300 %3281 Lod %f32_0 $ spirv-dis /tmp/spirv-dump/0xfail.comp | grep 'OpTypeImage %u' %119 = OpTypeImage %u32 2D 1 1 0 1 Unknown ``` One rejected module out of 38,809 — a depth-compared image (`2D 1`) with an integer sampled type (`%u32`), sampled by `OpImageSampleDrefExplicitLod` at line 5052, and `spirv-val` rejects precisely that instruction. That is #894's variant, and the variant is in `hookshot_programs.bin` (the log says `0 new, 0 compute variants`, so it is already cached), so it gets compiled again on every later start — which is also what #894 says. I have not sent the dumped module: it is built from game shaders. The `spirv-val` line above is the whole of what it says. ### Workaround `RX_VK_PRECOMPILE=0` in `hookshot_env.txt`, which skips the preparation. Tested in a nested Gamescope with `WAYLAND_DISPLAY=gamescope-0` (so the Gamescope-WSI layer is on, as in Game Mode) and with `ENABLE_VK_LAYER_VALVE_steam_fossilize_1=1` as Steam sets it: | run | preparation | result | |---|---|---| | 1 | left out | ok, 17,640 presents, 60 fps, ~4.5 min | | 2 | attempted | **crash**, same offset | | 3 | `RX_VK_PRECOMPILE=0` | ok, 11,520 presents, 60 fps, ~3.4 min | | 4 | control, no switch | **crash**, same offset | | 5 | `RX_VK_PRECOMPILE=0` | ok, 11,520 presents, 60 fps, ~3.4 min | | 6 | via `hookshot_env.txt` only | ok, 11,760 presents, 60 fps, ~3.4 min | Run 6 is the same setup as run 2, with only that file added, so the file is being read and it is what makes the difference. The cost is stutter when a scene is seen for the first time, since the shaders are then compiled during play. ### For those on Mesa 26.2.6 This issue mentions 26.2.6 specifically, but here it is 26.1.2 — so it is not a 26.2.6 regression, and the reported variants are the same thing. #894 and #834 (both open) look like the fixes. I have the full `hookshot_log.txt` from the run above (183 lines); say the word and I will paste it or send it. I left out the dumped module on purpose, since it is built from game shaders.

Combomamba commented

2026-11-09 03:29:48 +00:00

(Migrated from github.com)

SteamOS 3.9.5
Ryzen Z1 Extreme (RADV PHOENIX 12GB)
AMD RADV 26.1.99
Mesa 26.2.5
32GB RAM

hookshot_log.txt (Game mode crash)

hookshot_log.1.txt (Desktop Mode, ran on title screen for ~1min then closed window)

Getting a nearly byte-identical crash on my Lenovo Legion Go S (32GB Z1E SteamOS) every time I try to boot Hookshot v2.0.5 in game mode. Was also getting the crash in desktop mode until I updated Mesa drivers to 26.2.5, that fixed it for desktop mode, however I'm still getting the crash in game mode. SteamOS 3.9.5 Ryzen Z1 Extreme (RADV PHOENIX 12GB) AMD RADV 26.1.99 Mesa 26.2.5 32GB RAM [hookshot_log.txt (Game mode crash)](https://github.com/user-attachments/files/34561975/hookshot_log.txt) [hookshot_log.1.txt (Desktop Mode, ran on title screen for ~1min then closed window)](https://github.com/user-attachments/files/34561985/hookshot_log.1.txt)

NotRexed commented

2026-11-09 05:57:41 +00:00

(Migrated from github.com)

Fixed in v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6): the RADV crash right after "Preparing shaders" (write 0x40 in libvulkan_radeon.so, #803) was depth textures sampled as integer textures in the new compute variants (PR #834). Please update from the launcher; reply here or open a new issue if it still happens. Thanks to everyone who sent logs here.

Commenting is not possible because the repository is archived.