VKDoom crashes the Mesa AMD Driver [Workaround-ed (For Now)]

kinker31 · 2025-04-21 00:56:06

Context/Main Problem

For context, VKDoom is a fork of GZDoom, available through the AUR. Though I have the following problem primarily through the git version, I also have this problem as well with the nightly binaries, provided through a seperate AUR package.
I've also talked to VKDoom's respective Discord server about this, and the team's currently looking through the issue themselves as well.

As for my main problem, whenever I try running VKDoom anywhere but the terminal, the program crashes before it can even get to the title screen, citing an "address not set to object" error as the cause.
My best guess, helped from the guys over at the Discord, is that it might have something to do with the Mesa drivers, presumably clobbering information Vulkan needs to get the game to run in the first place.
How and/or why exactly it does this, except when directly run through the terminal, is beyond me at the moment.

Debug Logs

Running VKDoom through gdb, and with the vk_debug flag active, here's what I was able to get.
Keep in mind though, I wasn't able to get all the seperate debug info needed, since some of the bigger packages time out before they can be fully downloaded.

Thread 12 "vkdoom" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffceffe6c0 (LWP 10633)]
Downloading 9.11 K source file /usr/src/debug/mesa/build/../mesa-25.0.4/src/compiler/nir/nir_dominance.c
nir_block_dominates () at ../mesa-25.0.4/src/compiler/nir/nir_dominance.c:259
259	   return child->dom_pre_index >= parent->dom_pre_index &&
(gdb) backtrace
#0  nir_block_dominates () at ../mesa-25.0.4/src/compiler/nir/nir_dominance.c:259
#1  0x00007ffff2862cd0 in lower_rq_proceed () at ../mesa-25.0.4/src/amd/vulkan/nir/radv_nir_lower_ray_queries.c:556
#2  radv_nir_lower_ray_queries () at ../mesa-25.0.4/src/amd/vulkan/nir/radv_nir_lower_ray_queries.c:703
#3  0x00007ffff290446c in radv_shader_spirv_to_nir () at ../mesa-25.0.4/src/amd/vulkan/radv_shader.c:506
#4  0x00007ffff28eac34 in radv_graphics_shaders_compile () at ../mesa-25.0.4/src/amd/vulkan/radv_pipeline_graphics.c:2621
#5  0x00007ffff28edafd in radv_graphics_pipeline_compile () at ../mesa-25.0.4/src/amd/vulkan/radv_pipeline_graphics.c:3020
#6  0x00007ffff28ef818 in radv_graphics_pipeline_init () at ../mesa-25.0.4/src/amd/vulkan/radv_pipeline_graphics.c:3408
#7  0x00007ffff28f0462 in radv_graphics_pipeline_create () at ../mesa-25.0.4/src/amd/vulkan/radv_pipeline_graphics.c:3469
#8  radv_CreateGraphicsPipelines () at ../mesa-25.0.4/src/amd/vulkan/radv_pipeline_graphics.c:3620
#9  0x0000555555c95965 in ?? ()
#10 0x00005555557f5d50 in ?? ()
#11 0x00005555557f5b37 in ?? ()
#12 0x00007ffff70e1f74 in std::execute_native_thread_routine (__p=0x5555572be360) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
#13 0x00007ffff6ea370a in start_thread (arg=<optimized out>) at pthread_create.c:448
#14 0x00007ffff6f27aac in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Last edited by kinker31 (2025-04-22 17:55:11)

Lone_Wolf · 2025-04-21 10:49:30

The vkdoom-git PKGBUILD can use llvm/clang or "system compiler" (should be gcc on archlinux) .

Do clang buils and gcc builds both have the issue ?
Does building in a clean chroot make a difference ?

Which compiler is used to produce the nightly binaries ?

Moderator Note :
Moving to AUR Issues, Discussion & PKGBUILD Requests

kinker31 · 2025-04-21 13:31:59

I believe the first backtrace I provided was on gcc, so I built the package again, this time using clang.
Here's the backtrace for that fella:

Thread 11 "vkdoom" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcbfff6c0 (LWP 136951)]
nir_block_dominates () at ../mesa-25.0.4/src/compiler/nir/nir_dominance.c:259
259	   return child->dom_pre_index >= parent->dom_pre_index &&
(gdb) backtrace
#0  nir_block_dominates () at ../mesa-25.0.4/src/compiler/nir/nir_dominance.c:259
#1  0x00007fffee862cd0 in lower_rq_proceed () at ../mesa-25.0.4/src/amd/vulkan/nir/radv_nir_lower_ray_queries.c:556
#2  radv_nir_lower_ray_queries () at ../mesa-25.0.4/src/amd/vulkan/nir/radv_nir_lower_ray_queries.c:703
#3  0x00007fffee90446c in radv_shader_spirv_to_nir () at ../mesa-25.0.4/src/amd/vulkan/radv_shader.c:506
#4  0x00007fffee8eac34 in radv_graphics_shaders_compile () at ../mesa-25.0.4/src/amd/vulkan/radv_pipeline_graphics.c:2621
#5  0x00007fffee8edafd in radv_graphics_pipeline_compile () at ../mesa-25.0.4/src/amd/vulkan/radv_pipeline_graphics.c:3020
#6  0x00007fffee8ef818 in radv_graphics_pipeline_init () at ../mesa-25.0.4/src/amd/vulkan/radv_pipeline_graphics.c:3408
#7  0x00007fffee8f0462 in radv_graphics_pipeline_create () at ../mesa-25.0.4/src/amd/vulkan/radv_pipeline_graphics.c:3469
#8  radv_CreateGraphicsPipelines () at ../mesa-25.0.4/src/amd/vulkan/radv_pipeline_graphics.c:3620
#9  0x0000555555e5c657 in GraphicsPipelineBuilder::Create(VulkanDevice*) ()
#10 0x0000555555968817 in ??? ()
#11 0x0000555555965c28 in VkRenderPassManager::WorkerThreadMain() ()
#12 0x00007ffff62e1f74 in std::execute_native_thread_routine (__p=0x555557d33aa0)
    at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
#13 0x00007ffff60a370a in start_thread (arg=<optimized out>) at pthread_create.c:448
#14 0x00007ffff6127aac in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

I attempted giving a chroot install a shot, but couldn't quite get it to work; Chroot is surprisingly hard when dependencies have to come from the AUR as well.

kinker31 · 2025-04-22 17:54:13

Upd8: Seems like the main issue behind all of this is how rayquery creation works with AMD cards.
Still not entirely sure if this is an issue on Mesa's end, or if it's in VKDoom's hands at this point, but at least I can say for now that the program might be functional again, but no smoking.

Here's the relevant git commit, for anyone looking in the present or future.

Arch Linux

#1 2025-04-21 00:56:06