JVM crash in G1 GC while running Minecraft Paper server (Microsoft OpenJDK 25.0.1)

[CatRoman05]

Describe the bug

The JVM crashes randomly while running a Minecraft Paper server. The crashes occur most frequently when players interact with villagers (trading GUI), but they have also happened while interacting with other inventories.

Paper developers reviewed the crash log and concluded that this is a JVM crash rather than a Paper bug. They suggested reporting it to Microsoft because they had already seen another similar JVM crash.

Desktop (please complete the following information):

OS & version:
Windows 10 64-bit (Build 19041.5915)

MSFT Build of OpenJDK Version:

Microsoft OpenJDK 25.0.1+8

To Reproduce:

Unfortunately, I do not have reliable reproduction steps.

The crash happens randomly while the Paper server is running. It occurs most often when opening the villager trading interface, although it has also happened while interacting with other inventories.

Expected behavior

The JVM should not terminate unexpectedly. The server should continue running normally.

Screenshots, Logs etc

Attached:

• hs_err_pid9264.log

The crash log shows an internal JVM failure:
Internal Error (g1HeapRegionManager.cpp:55)
guarantee(...) failed: master free list MT safety protocol at a safepoint

Additional context

Paper version:
26.1.2

The Paper issue was closed because the developers determined that the crash occurred inside the JVM rather than in Paper:
PaperMC/Paper#14129

[github-actions]

Thank you for the report!
It looks like you are reporting that the game Minecraft crashed for you. Please try the following:

• Update your graphics drivers, see this Minecraft Help Center article, section "Update your Video Card Drivers";
  often Minecraft crashes are caused by outdated graphics drivers
• In case you are using mods, try disabling them one by one until you find the mod causing the crash, then report the crash to the mod author
• If you are using a third-party launcher, try the official launcher instead

If none of the above helped, and you are still experiencing the crash with the official launcher and without any mods installed, please submit this issue over at the Mojang bug tracker. Please search for existing reports first; in case you do not find any, create a new report and let us know about the issue number here (e.g. MC-123456).
The Mojang team will take the first look. If an OpenJDK bug is identified, the Mojang team will contact the Microsoft Build of OpenJDK team to address the issue.

[CatRoman05]

hs_err_pid9264.log

[CatRoman05]

The bot misidentified this; it is not a Minecraft error. A Paper developer responded that the crash is related to the JVM and that this is not the first such instance today.

[karianna]

Thanks CatRoman05 - we're investigating this internally - over to Monica Beckwith (@mo-beck)

[mo-beck]

Thanks CatRoman05, and thanks to the Paper folks for triaging this over to us. You're right that this isn't a Paper or Minecraft bug. The crash originates in the JVM.

We've root-caused it. The signature in your hs_err:

Internal Error (g1HeapRegionManager.cpp:55)
guarantee(...) failed: master free list MT safety protocol at a safepoint

is associated with G1's time-based heap sizing feature, which is specific to the Microsoft Build of OpenJDK and helps returns idle heap memory back to the OS.

The feature runs a periodic, timer-driven evaluation that can shrink the heap (uncommit regions) independently of GC. Under a particular timing window, that shrink path could touch G1's master free list without the required MT-safety protocol at a safepoint. When that happens, the JVM trips the guarantee above and aborts.

The bug is timing-dependent, which matches the behavior you're seeing: intermittent crashes with no reliable reproduction pattern.

Immediate mitigation: you can turn the feature off. Add these JVM flags to your server startup:
-XX:+UnlockDiagnosticVMOptions -XX:-G1UseTimeBasedHeapSizing

That reverts G1 to its standard heap-sizing behavior. The only tradeoff is that idle heap memory will no longer be automatically returned to the OS.

Fix status: We've already fixed the underlying issue by ensuring the heap shrink path is properly synchronized with the relevant G1 free-list operations, and we've added a regression test that exercises this specific concurrent uncommit path so it can't silently return. The fix is currently going through stress and regression testing and is targeted for an upcoming OpenJDK 25 update release.

If you're able to apply the mitigation flags, I'd be interested to hear whether the crashes stop.

Thanks for the detailed report and the hs_err log. The error signature made it possible to identify the root cause quickly.