#[SPZ2-5984] [1.0.3-rc3] [Linux] Crashes on startup with vulkan

136 messages · Page 1 of 1 (latest)

wispy willow
#

I've been seeing very weird crashes during the game startup (when the game bar is shown). The scenario is the same:

  • The loading bar is running
  • Then the game hangs
  • Then everything crashes and triggers a device loss with this dmesg log:
[  780.787787] amdgpu 0000:c1:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:6 pasid:193)
[  780.787804] amdgpu 0000:c1:00.0: amdgpu:  Process shapez 2.x86_64 pid 14758 thread UnityGfxDeviceW pid 14850
[  780.787814] amdgpu 0000:c1:00.0: amdgpu:   in page starting at address 0x000000030193c000 from client 10
[  780.787822] amdgpu 0000:c1:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00601030
[  780.787828] amdgpu 0000:c1:00.0: amdgpu:      Faulty UTCL2 client ID: TCP (0x8)
[  780.787834] amdgpu 0000:c1:00.0: amdgpu:      MORE_FAULTS: 0x0
[  780.787839] amdgpu 0000:c1:00.0: amdgpu:      WALKER_ERROR: 0x0
[  780.787844] amdgpu 0000:c1:00.0: amdgpu:      PERMISSION_FAULTS: 0x3
[  780.787848] amdgpu 0000:c1:00.0: amdgpu:      MAPPING_ERROR: 0x0
[  780.787853] amdgpu 0000:c1:00.0: amdgpu:      RW: 0x0

(or similar)

This happens with both proton and native linux when using vulkan, but not when using dx12 via proton.

Kernel: Linux 6.19.13-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 21 Apr 2026 23:38:22 +0000 x86_64 GNU/Linux
mesa: mesa-1:26.0.5-1 from arch repos
GPU: uhhh i have no idea it's whatever igpu you get in an amd 7040u (mobile APU)

loud hedgeBOT
#

Thank you for reporting this bug! Our team will review your report soon.
Feel free to add more details in follow-up messages — we're also scanning for duplicate reports automatically now.
📨 There are currently 104 reports awaiting team review. Due to the high volume, it may take a little longer for us to get to yours.
⏰ Our team is off on weekends, so it may take a bit longer for us to review your report. Thank you for your patience!

📋 Log files help us investigate issues. You can find yours here:
• Linux: ~/.config/unity3d/tobspr Games/shapez 2/Player.log

💾 Savegame files (.spz2) are very helpful if relevant to the issue!
Export via Main Menu → Play → click the download icon on the relevant savegame.
You can also find them here:
• Linux: $XDG_CONFIG_HOME/unity3d/tobspr Games/shapez 2/

wispy willow
#

oh hmm now that i think about it, it might not help that i installed all two or three amd gpu drivers in search of the one that would work with the gpu profiler (they did not)

wispy willow
#

okay no it still crashes

loud hedgeBOT
# wispy willow
📋 Log File Analysis

Log Analysis (Player.log):

  1. Fatal Runtime Error: A fatal error occurred in the mono runtime or one of the native libraries.
  2. Native Fault Reporting Error: An error occurred in the native fault reporting system, resulting in some diagnostic information being unavailable.
stoic idol
#

Most likely this is same as #1423073726035005450 (AMD GPU crashes on Linux)

#

Oh, but your report is interesting... if it happens with both native and Proton versions on Vulkan, that means either the game is doing something wrong while rendering, or the RADV driver can't handle that properly

wispy willow
stoic idol
#

These two are the same. Try running the game with validation layers and see if you get the same errors

wispy willow
#

sure

wispy willow
stoic idol
#

Hm, I've seen reports about the game working with proprietary drivers but having bad performance. Your GPU is integrated unlike most crash reports, but the game is unstable on my laptop with "AMD Radeon 680M" integrated graphics too. I'll do more testing later

wispy willow
#

it does work with one of the launch options under proton and i THINK radv does make it a little faster? not sure though

#

uh, how do i enable vulkan validation layers even

#

i mean i know how to enable them for everything but like

stoic idol
#

See the thread I linked

wispy willow
#

thats not gonna go great

#

ahh okay

stoic idol
#

I just ran the game on my laptop and it crashed after loading. That's slightly different from startup crashes but also I'm on GNOME here and not sway 🙃

wispy willow
#

wdym "after loading"?

#

hmm okay now running the game just crashes on startup

#

without a logfile i think no i might just be bad

#

yeah same crash (before loading) as the one in the posted log

#

running outside of steam allowed the game to symbolize itself

📎 Player.log
loud hedgeBOT
#
1. [SPZ2-5984] — ✨ 85% similar

Game crashes when using a RX6600XT or RX6600 when using Vulkan
To Do • Priority: High • Fix: Probably Never • Game: 1.0.0-beta2

shapez 2 crashes when reaching the main menu while using the Vulkan graphics API on AMD GPUs, including the RX 6600, RX 6600 XT, RX 9060 XT, and RX 5700 XT. The crash is triggered by launching the game with Vulkan, particularly with graphics settings above low. This appears to be a regression introduced in Unity 2022.3.62f2, as builds using the older Unity 2022.3.42f1 do not exhibit the crash. Since Unity no longer releases new LTS updates for the 2022.3 series without an enterprise license, ...
💬 Threads: [1.0.0-closed-beta] Changing Graphic Set

#
2. [SPZ2-3663] — ✨ 78% similar

Crash on startup
Done • Priority: Medium • Fix: Version 0.0.9 • Game: 24.2.2 • Resolution: Won't Fix

shapez 2 crashes on startup with a SIGSEGV error when running natively on Linux, likely triggered by recent OS package updates (such as mesa, mutter, vulkan-loader, or xwayland). The game was previously working but newer package versions broke compatibility. Running under Proton appears to work as a workaround, though sound issues were also reported. The crash occurs in native code before the menu is displayed. This is not something the development team can fix on their end, so using Proton i...
💬 Threads: [1.0.3-rc3 Linux] Game launches for a fe

#
3. [SPZ2-1825] — 👀 65% similar

Vulkan: Out of memory -> Causing Native Crashes for lots of players
Done • Priority: Highest • Fix: OLD Early Access • Game: 0.0.0-alpha13 • Resolution: Done

Vulkan graphics API is running out of VRAM (video memory) causing native crashes and even bluescreens for many players, particularly those with graphics cards that have limited memory. The crashes occur during game preloading when loading the GlobalScene, before players can even start playing. Investigation revealed that textures use excessive memory, with the game initially using 2.0 GB VRAM at startup in 1920×1080 resolution. Texture compression settings were optimized to reduce VRAM usage ...

#
4. [SPZ2-6232] — 👀 55% similar

Shapez 2 can crash when switching graphics settings while using Linux.
To Do • Priority: Critical • Fix: None • Game: 0.1.1

shapez 2 can crash or become unstable on Linux when changing and applying graphics settings such as resolution and window mode. This occurs when users navigate to Settings > Graphics and apply changes. Additionally, some users experience crashes at startup, potentially due to the application attempting to apply outdated graphics settings from a previous version before the settings refactor in rc1. The expected behavior is that the game remains functional and stable after applying graphics cha...
💬 Threads: [1.0.2-rc1] Crash when hitting apply in

#
5. [SPZ2-6003] — 👀 45% similar

Linux: Crash when losing focus if in full screen or borderless mode
To Do • Priority: Highest • Fix: Probably Never • Game: 6.5.5

On Linux (KDE Plasma and Ubuntu), shapez 2 crashes instantly when the game loses focus while in fullscreen or borderless screen mode. This is triggered by Alt-Tab, the Windows key, or clicking outside the game window. The crash occurs immediately upon focus change, stopping the game entirely. The expected behavior is that shapez 2 should continue running regardless of screen mode when focus is lost. The issue was previously observed on Bazzite but has since resolved there for unknown reasons.
💬 Threads: [0.1.1] Linux - Game crash on FN key pre

#
6. [SPZ2-3849] — 👀 35% similar

Minimize Game with Vulkan Crashes game
Done • Priority: High • Fix: None • Resolution: Won't Fix

When playing shapez 2 in windowed mode at 1680x1050 resolution using the Vulkan graphics backend, minimizing the game window causes an immediate crash. The player normally uses borderless mode but was testing the minimize functionality in windowed mode. The crash does not occur when using DirectX. This appears to be an engine-level issue with Vulkan's handling of window minimization in windowed display mode.
💬 Threads: [0.0.9-xmas] Minimize Game with Vulkan C

Found 6 similar reports • Searched 3,521 reports • Use /check-duplicates to recheck
wispy willow
#

it crashes in mesa, src/vulkan/runtime/vk_render_pass.c:2512 ```c
static void
end_subpass(struct vk_command_buffer *cmd_buffer,
const VkSubpassEndInfo *end_info)
{
const struct vk_render_pass *pass = cmd_buffer->render_pass;
const uint32_t subpass_idx = cmd_buffer->subpass_idx;
assert(subpass_idx < pass->subpass_count);
const struct vk_subpass *subpass = &pass->subpasses[subpass_idx]; // <--- this line crashes

#

okay im gonna blame radv

#

MESA_VK_DEVICE_SELECT=10005:0 MESA_VK_DEVICE_SELECT_FORCE_DEFAULT_DEVICE=1 makes the game start

#

(this forces a software renderer)

#

its not fast, but it does work

stoic idol
#

Does the game not fallback to OpenGL if it detects a software renderer?

wispy willow
#

uhhhhh is it meant to

#

it starts so slowly that im pretty sure the answer is no

stoic idol
#

I've seen the game run very slowly when in OpenGL mode. You can confirm the renderer by looking at the version in bottom right corner of the screen

wispy willow
#

well its so slow it doesnt even get to that point before i got bored of waiting

stoic idol
#

It is a RADV bug (otherwise the game would consistently crash on NVIDIA GPUs too) but many Vulkan games work fine so I'd say the validation errors I got are probably relevant. Don't really have time to do extensive testing right now though

wispy willow
#

oh, yeah

#

i think its just opengl fallback being slow then

#

how do i disable the fallback

#

you probably shouldnt show this warning for igpus

image.png
#

yeah i also get the vvl errors so its probably just some weird side effect of how radv implements semaphores

#

which also explains why directx works

stoic idol
#

Could it be a different but related bug? Also I'm interested in understanding how you got from the crash to mesa source code, I am not that good at debugging 😅

wispy willow
#

if you have debug symbols available, it will just contain the path

#

and line number

stoic idol
#

Yeah, but it's a 2000-line stack with all threads. Did you use a proper text editor to search for relevant symbols? 😅

wispy willow
wispy willow
#

with addresses which are basically unique

#

and then you have all of the threads

#

so yes just use a text editor to find the one stack trace that is from the crashing thread

stoic idol
#

Good to know, thanks! Some day I'll learn how to debug native code...

wispy willow
#

i tracked down the issue some more and i figured out how to """fix""" the issue

step 1: install and enable my awful vulkan layer
step 2: just works

layer: https://git.sr.ht/~pitust/fix_layer

#

the vulkan synchronization is kinda broken: there is only one semaphore that is used to sync between vkQueueSubmit and vkQueuePresentKHR, which is not allowed (you need one semaphore per image acquired from vkAcquireNextImageKHR)

so my hack has its own pool of one semaphore per frame and does sync with those instead

#

ok maybe it doesnt work so well

#

idk my whole computer just crashed although i have no idea if it has anything to do with my layer (but its amdgpu so no idea)

wispy willow
#

i think that was an unrelated linux moment so yes the issue is just incorrect semaphore reuse

restive rain
#

I'm genuinly very surprised that you're having the crash though because it works fine on radv for me

#

but I do know that there is a race condition within the mesa driver presentation sync code, and so if the application is only using a single semaphore that could cause inconsistent behavior due to that race condition

stoic idol
restive rain
#

I'm currently looking into it because I'd be shocked if the unity Vulkan code was doing that

#

so unless they're using a custom vulkan implementation rather than just letting unity do it, I'd be very surprised to see a bug like this

stoic idol
#

There must be tons of other Unity games that are fine. It could be incorrect usage of high-level Unity APIs or misconfiguration too. What's your setup like? There are indeed people who can run the game fine with AMD GPUs, but I've seen both crashes and success on the same VID:PID combo at least once

narrow bobcat
#

Shapez 2 is not the only game I know with sus behavior on vulkan
But it’s the only one that crashed

restive rain
stoic idol
#

Yeah, 9070 XT was it

restive rain
#

I can test my laptop with raphael integrated

stoic idol
#

What desktop(s) though? Did you test windowed mode and trying to resize it (if possible on your desktop/WM)?

restive rain
#

I have no validation messages here even when configured to be aggressive using vkconfig

restive rain
#

and in windowed mode it doesn't let me resize

narrow bobcat
#

That’s normal

stoic idol
#

Well I could resize in windowed mode on sway and the game did adapt properly. But this was some weird configuration that let me run crashless in the first place, don't remember what that was

narrow bobcat
#

I don’t remember being able to resize on both Linux, Mac and windows

restive rain
#

well that's only if your DE respects the window properties

stoic idol
#

The window is not configured to allow resizing but the game can adapt UI to any resolution. I've heard of Windows crashes related to resolution changes though so initially I thought this was related

restive rain
#

wayland puts a lot of responsibility on the display server

#

oh actually I wonder how it behaves on x11

stoic idol
#

No validation errors at all is weird though. Are you sure it gets applied? I've seen the game load libraries from Steam Runtime, that might have overridden your configuration. Have you tried launching outside of Steam (must use --disable-store-sdk for that)?

restive rain
#

yeah I just did some testing and looks like it just wasn't forwarding stdout but logging it to a file I got some

restive rain
#

mostly just racing reads caught by the synchronization validation

#

ok looks like those only happen on the actual startup screen but go away before the main menu

stoic idol
#

Most validation errors I see are handled fine, but there are two validation errors that occur right after an attempt to resize the game window, which happens if you force (un-)fullscreen it on sway and Hyprland. I also had the game crash by using volume keybindings on GNOME running on a laptop with integrated graphics, though I don't remember if I tried running the game with validation layers. On KDE this is also the common report - anything that unfocuses the game will crash, and a common example is changing audio volume using keyboard shortcuts. I have not investigated whether SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0 affects that.

The validation errors occuring right before crashing to me are a strong hint that these calls are the root cause for the crash. The game not crashing on all RADV devices is easiest explained by implementation differences across devices, and 9070 XT might've been seemingly randomly affected due to driver updates (i.e. the bug doesn't happen on some older/newer version of kernel/mesa/vulkan-radeon/etc.)

restive rain
#

changing audio volume using keyboard shortcuts
interesting I've never experienced this
The validation errors occuring right before crashing to me are a strong hint that these calls are the root cause for the crash
yeah the actual crash dump indicates that as well. the actual crash is caused by a race condition within the mesa driver, and it won't crash if that race condition doesn't happen to cause an issue, usually due to the frame taking a short enough time to render. the cash is within the radv driver itself which is device agnostic, so I wouldn't expect that its caused by different implementations, unless this is revealing a bug in the actual amdgpu kernel module

stoic idol
#

Hm, if this is a race condition then that must be the reason why the game sometimes seems to just work for me 🤔

restive rain
#

yeah I have a patch for it but it massively hurts performance so I decided against making a pull request for it

stoic idol
#

That's crazy. I wish I was this smart 😅

restive rain
#

you have to sync the individual frame buffers to each other, which not only is not required by the vulkan spec but is also documented as not happening lol

restive rain
#

it's been a very fun process, especially since I'm able to spend time optimizing it in a way that you simply can't with existing game engines, so it runs at about 20k fps on my hardware, and 80 fps on a gt710 lol

#

I don't see anything in my decomp that would indicate that this bug is caused by shapez so I'm going to test a few other unity games and see if this is just a unity bug

#

ok so I created an empty unity project, switched the renderer to vulkan, restarted it, and it crashed. this is not a good sign.

stoic idol
#

(Does Unity know lmao)

restive rain
#

awesome this appears to be a unity bug that is also present in the editor
time to find out how to make a bug report!

stoic idol
#

But shapez itself runs fine for you, doesn't it? Unless you've tested with Steam Runtime and that somehow absorbs the failure

restive rain
#

it does, because a misuse of the Vulkan specification does not mean it will break things, it just is undefined behavior

#

and in this case what happens is that there's a race condition in the mesa driver caused by failing to properly sync swapchain presents

#

the editor outright crashes due to a std::vector assert for indexing out of bounds, but it's caused by the same issue

#

bug report created 👍

wispy willow
#

or in hw

#

because i think i originally hit crashes with amd propriatory drivers (i think so, anyway?)

#

unless they just both implement it the same way

restive rain
#

amd proprietary linux drivers are nearly a year old they stopped supporting them in may of last year

#

they're literally not even in the arch repos anymore

#

and I promise you I can show you the exact lines in the mesa driver that cause this. I have a local patch that fixes it.

wispy willow
#

and i think they were the system default

wispy willow
#

wait

#

how do you even fix that

#

hmm actually how does a binary semaphore even get mapped to wayland

restive rain
restive rain
restive rain
restive rain
wispy willow
#

awesome

wispy willow
#

like the whole laptop resets

restive rain
#

If it's happening with the environment variables then that's caused by invalid usage of the Vulkan API

wispy willow
wispy willow
restive rain
#

the env variables are documented here

loud hedgeBOT
#

[SPZ2-5984] [1.0.3-rc3] [Linux] Crashes on startup with vulkan