[26.2] Hard game crash (EXCEPTION_ACCESS_VIOLATION in AMD driver) while chest editor is open – glReadPixels in MagnifierRenderer #7

Summary

Minecraft crashes hard (the whole Java process dies, no Minecraft crash report) whenever the Absolute Order chest editor is open. It doesn't only happen when using the magnifier – clicking buttons or doing anything else in the editor can trigger it too.

The crash happens inside the AMD OpenGL driver (atio6axx.dll), but in all 3 crashes the call comes from the same place in Absolute Order: glReadPixels in MagnifierRenderer.render.

Environment

• Absolute Order: 2.0.0 (AbsoluteOrder-2.0.0-fabric-mc26.2.jar)
• Minecraft: 26.2
• Fabric Loader: 0.19.5
• Java: Microsoft OpenJDK 25.0.1
• Launcher: Prism Launcher
• OS: Windows
• GPU: AMD Radeon RX 9070 XT , driver Adrenalin version: 26.10.1
• ~124 other mods installed (list attached)

Steps to reproduce

1. Open any chest
2. Open the Absolute Order editor
3. Use the editor normally (magnifier, clicking buttons, switching things)
4. After a short time the game closes instantly

It happens very often, not just once.

What the crash logs show

All 3 hs_err logs are identical in the important part:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) ... writing address ...
Problematic frame: C [atio6axx.dll+0x2406963]

Java frames:
org.lwjgl.opengl.GL11.glReadPixels
 <- io.github.marcsanzdev.chestseparators.client.ui.MagnifierRenderer.render(GuiGraphicsExtractor, int, int, boolean)+164
 <- EditorRenderer.renderMagnifier
 <- EditorRenderer.render
 <- ChestSeparatorsEditor.render
 <- AbstractContainerScreen (mixin chestseparators$renderEditorOverlay)
 <- AbstractContainerScreen.extractRenderState

So the driver is writing past the end of the ByteBuffer passed to glReadPixels.

Why it crashes on "random" clicks

EditorRenderer.render calls renderMagnifier every frame while the editor is open, so glReadPixels runs every frame – not only when the magnifier is actually used. Whatever I click last just happens to be the frame where it crashes.

Possible cause (my guess)

The buffer size itself looks right (size*size*4, GL_RGBA / GL_UNSIGNED_BYTE). But the pixel pack state is never set before the read, so if something else (vanilla 26.2 or another mod like Sodium/Iris) left a different state, the driver writes more data than the buffer can hold:

• GL_PACK_ROW_LENGTH not 0 → driver uses a larger row stride → overflow
• GL_PACK_SKIP_ROWS / GL_PACK_SKIP_PIXELS not 0
• a GL_PIXEL_PACK_BUFFER still bound
• the read happens during extractRenderState (26.2), where the bound read framebuffer isn't guaranteed

Also, Window.getWidth()/getHeight() are used for clamping – the actual framebuffer size can differ from that.

Suggested fix

• Before glReadPixels: unbind GL_PIXEL_PACK_BUFFER, set GL_PACK_ALIGNMENT = 1 (or 4), GL_PACK_ROW_LENGTH = 0, GL_PACK_SKIP_ROWS = 0, GL_PACK_SKIP_PIXELS = 0 – and restore the old values afterwards
• Bind the main render target as read framebuffer and use its real size
• Only read pixels when the magnifier is actually active, not every frame (also better for performance – glReadPixels stalls the GPU)
• Ideally use Minecraft's own readback API (copy texture to buffer) instead of raw GL calls

Attachments

• latest.log
• modlist.md
• hs_err_pid2052.log
• hs_err_pid7484.log
• hs_err_pid12284.log
• hs_err_pid23964.log