Sending the system to sleep causes a crash with the Vulkan rendering backend

Thank you for helping us improve Minecraft! We saved your files:

This crash does not appear to affect Linux.

I’m unable to reproduce this. Sending my PC to sleep with snapshot 9 loaded did not make it crash

What specific operating system or build are you using? Are you sure Vulkan is enabled?

…why wasn’t this automatically reopened upon response like MC-311284 was?

I guess that works too, then

Tried with vulkan actually enabled and still no repro

Perhaps this is software or windows version dependent. What exactly are you using?

Confirming this on Linux with the 26.3 release (please add 26.3 to affected versions).

Same exception and stack trace as the attached reports:
java.lang.IllegalStateException: GPU timeout attempting to acquire next frame
TOP_OF_PIPE = END_RENDER_PASS GUI after blur
BOTTOM_OF_PIPE = END_RENDER_PASS GUI after blur
at com.mojang.renderpearl.backend.vulkan.VulkanGpuSurface.acquireNextTexture(VulkanGpuSurface.java:271)
at com.mojang.renderpearl.frontend.FrontendGpuSurface.acquireNextTexture(FrontendGpuSurface.java:71)
at net.minecraft.client.Minecraft.renderFrame(Minecraft.java:1330)

System:

• Arch Linux, kernel 7.2.8, Fabric (Sodium, Lithium; also happens in the main menu, no world loaded)

• AMD Ryzen 5 5600H with integrated Radeon Vega (Cezanne), Mesa RADV 26.2.3

• Wayland compositor (niri), game window running through XWayland (VK_KHR_xlib_surface), fullscreen, VSync on

Steps:

1. Leave the game running (here: on the title screen).

2. Close the laptop lid -> screen locks, system enters s2idle.

3. Resume.

The game crashes about 2 seconds after resume. At that moment the window is not visible (lock screen on top), and during suspend/resume the compositor briefly loses DRM master because of a VT switch, so the surface cannot present for a few seconds.

So this is not specific to Windows or to the proprietary AMD driver: it also happens on Mesa RADV on Linux. It looks like vkAcquireNextImageKHR hits its timeout while the surface temporarily cannot present, and the game treats that timeout as fatal instead of waiting or recreating the swapchain. MC-310118 (hidden window, 0x0 swapchain) was fixed, but an occluded and non-minimized window after sleep still crashes.

Can confirm this on Linux for 26.3. The game sometimes freezes and crashes if the window is in the background or on another workspace for a few seconds. This might be due to the display server not rendering the window when hidden so it times out.