Server thread hangs for minutes inside native Rapier3D.step (watchdog kill), even with no players near sub-levels

[ShinjiraCode]

Context

Environment

• Minecraft 1.21.1, NeoForge 21.1.248 (also seen on 21.1.251)
• Sable 2.0.5 (sable_rapier 1.21.1-2.0.5), Create Aeronautics (bundled) 1.3.2, Create 6.0.10
• C2ME 0.4.0-alpha.0.120, Lithium 0.15.4, ModernFix 5.27.24, ~214 mods total
• Dedicated server, Linux x86_64 (Docker/Pterodactyl container), Java 21.0.7
• Host CPU: AMD EPYC 7313, 32 threads visible to the process (no CPU quota on the container)

What happens

The server thread periodically stalls inside Rapier3D.step for tens of seconds up to several minutes, then either recovers or gets killed by the watchdog. Examples (UTC):

• 2026-09-14 13:08: watchdog crash after ~120 s (max-tick-time 120000); server thread was in Rapier3D.step (stack below)
• 2026-09-16 12:49: "Can't keep up! Running 138257ms behind"
• 2026-09-16 13:35: "Can't keep up! Running 233413ms behind"
• 2026-09-16 17:19: "Can't keep up! Running 100180ms behind"

The 12:49 and 13:35 freezes happened with no real players online: only a Carpet fake player keeping a base loaded, near two small sub-levels (about 8x1x5 and 9x10x11 blocks). No terrain generation was happening. Freeze lengths vary a lot (20 s to over 5 min), which looks more like a hang than heavy load.

Server thread stack (watchdog, 2026-09-14)

"Server thread" RUNNABLE
  at dev.ryanhcode.sable.physics.impl.rapier.Rapier3D.step(Native Method)
  at dev.ryanhcode.sable.physics.impl.rapier.RapierPhysicsPipeline.physicsTick(RapierPhysicsPipeline.java:159)
  at dev.ryanhcode.sable.sublevel.system.SubLevelPhysicsSystem.tickPipelinePhysics(SubLevelPhysicsSystem.java:279)
  at dev.ryanhcode.sable.sublevel.system.SubLevelPhysicsSystem.tick(SubLevelPhysicsSystem.java:238)
  at dev.ryanhcode.sable.api.sublevel.SubLevelContainer.lambda$tick$0(SubLevelContainer.java:147)
  at dev.ryanhcode.sable.api.sublevel.SubLevelContainer.tick(SubLevelContainer.java:147)
  at dev.ryanhcode.sable.api.sublevel.ServerSubLevelContainer.tick(ServerSubLevelContainer.java:90)
  at net.minecraft.server.level.ServerLevel.handler$gaa000$sable$tickPlotContainer(ServerLevel.java)
  at net.minecraft.server.level.ServerLevel.tick(ServerLevel.java)
  at net.minecraft.server.MinecraftServer.tickChildren(MinecraftServer.java:1037)

Full crash report: see the Crash Report field below.

Profiler

spark profile covering the 17:17-17:19 freeze (--only-ticks-over 500): https://spark.lucko.me/qSqiCrP7ql
About 36 s of server-thread time was spent inside Rapier3D.step during that freeze.

The Shtreimel add-on measured the overworld physics slice at EWMA 1016 ms / max 20161 ms just before one of the freezes. Its crash-report header on another watchdog crash also showed high physics times in dimensions with no loaded sub-levels (e.g. aether: EWMA 312 ms, max 6245 ms).

Native library notes

The extracted sable_rapier_x86_64_linux.so links rayon-core 1.13.0 (global pool, honours RAYON_NUM_THREADS), parry3d 0.26.0 (includes partitioning/bvh/bvh_optimize.rs) and rapier from git 38e92f1. With no CPU quota, the global pool sizes itself to all 32 host threads.

Possibly related:

• PhysicsPipeline::step hangs in join_deferred_bvh_optimize with parallel enabled dimforge/rapier#1008: PhysicsPipeline::step hangs in join_deferred_bvh_optimize with the parallel feature and 2+ worker threads (no hangs with 1 worker)
• Server watchdog hang: HandleBlockEntity removes Rapier constraint during physics step #1431: a native Rapier call never returns when physics state is modified during a step

Workaround being tested

Running with RAYON_NUM_THREADS=1 since 2026-09-19. I'll report back whether the freezes stop.

Crash Report

https://mclo.gs/HlbRRql