Bedrock 1.26.43.1 OOM-crashes on startup regardless of world/packs/config

Summary

Bedrock Dedicated Server for Linux, version 1.26.43.1 (branch r/26_u4, build 49104928), crashes on startup due to an out-of-memory condition — the process is killed by the Linux kernel OOM killer after its resident memory jumps to ~5-6GB within seconds of launch, well before the "Server started" log line and before any player has connected. This reproduces on a minimal, near-vanilla server (no custom packs, a 17MB world, default-range settings), and is not present in the previous build (1.26.32.2) running the identical config/world.

Environment

• OS: Ubuntu (glibc 2.39), Docker container (Crafty Controller)

• CPU: x86_64, AVX2 + BMI2 present

• RAM: 7.5GB physical + 4GB swap

• Server management: Crafty Controller, server run via ./bedrock_server inside the container

Version info (from server log)

Version: 1.26.43.1
Build ID: 49104928
Branch: r/26_u4
Commit ID: 85f9f8204d8a04f4e27d119f83ce61cea4774c1f
Configuration: Publish

Steps to Reproduce

1. Take a small (17MB) existing world with no custom resource/behavior packs.

2. Use a server.properties with unremarkable settings (view-distance=32, tick-distance=4, max-threads=8, max-players=10, gamemode=survival, difficulty=peaceful).

3. Start bedrock_server (build 49104928 / 1.26.43.1).

4. Observe resident memory (RSS) via ps aux — it climbs to ~5-6GB within approximately 3 seconds of process start.

5. On a memory-constrained host, the OS OOM killer terminates the process before "Server started" is ever logged. On a host with enough headroom, the allocation itself may simply be rejected up front (__vm_enough_memory: ... not enough memory for the allocation in kernel log) unless vm.overcommit_memory=1.

Expected Behavior

Server starts normally, using a memory footprint proportional to world size/config (historically a few hundred MB to low single-digit GB for a small world with modest settings) — matching the behavior of the previous build (1.26.32.2), which runs this exact same world/config/packs with an RSS of only ~13MB shortly after startup.

Actual Behavior

Process resident memory spikes to ~5-5.8GB within seconds of startup, before world loading completes and before any player connects. Confirmed via kernel log:

oom-kill:constraint=CONSTRAINT_NONE,...,task=bedrock_server,pid=2435320,uid=1000
Out of memory: Killed process 2435320 (bedrock_server) total-vm:136763628kB, anon-rss:5781708kB, file-rss:8kB, shmem-rss:0kB, UID:1000 pgtables:12128kB oom_score_adj:0

Note the total-vm figure (~130.4GB) was consistently identical across every separate process launch tested, regardless of configuration changes — suggesting the binary reserves a large, fixed-size virtual memory region unconditionally at startup.

Console output at crash (no further lines logged after this point)

[INFO] Starting Server
[INFO] Version: 1.26.43.1
[INFO] Session ID: ...
[INFO] Build ID: 49104928
[INFO] Branch: r/26_u4
[INFO] Commit ID: 85f9f8204d8a04f4e27d119f83ce61cea4774c1f
[INFO] Configuration: Publish
[INFO] Contents of server.properties: {}
[INFO] Level Name: FamilyWorld
[INFO] Profiler config ('bootstrap.json') load result: success=1, errorMessage=(null)
[INFO] No CDN config file found at: cdn_config.json for dedicated server
[INFO] Game mode: 0 Survival
[INFO] Difficulty: 0 PEACEFUL
[WARN] Content logging to console is disabled. Enable it with content-log-console-output-enabled=true in server.properties
[INFO]
#####################################################
#               LOADING VANILLA WORLD               #
#####################################################
(process killed here — no further output, no crash report written since SIGKILL from OOM killer bypasses the userspace crash handler)

Troubleshooting already performed (ruling out local causes)

• GLIBC/shared libs: ldd shows all libraries resolve; binary requires only GLIBC 2.26, host has 2.39. Not the cause.

• Overcommit strictness: vm.overcommit_memory was already 0 (heuristic). Even after setting to 1 (always overcommit, no sanity check), the process still gets OOM-killed once it actually touches ~5GB of resident memory — the allocation itself is real, not just an oversized virtual reservation being rejected.

• World size: World is 17MB. Not proportional to a multi-GB memory requirement.

• server.properties config: Lowering view-distance from 32 to 10 made no measurable difference — RSS still hit ~4.9GB within ~3 seconds. Not view-distance-driven.

• Custom packs: The server tested has zero custom resource/behavior packs. A separate server on the same host with 11 behavior packs + 9 resource packs shows the same crash pattern. Not pack-related.

• Download corruption: Ruled unlikely — the crash size/timing is highly consistent (same ~5-6GB RSS, same ~3 second timing) across many independent process launches, which is inconsistent with random corruption.

• Previous build works fine: Rolling the identical server (same world, same server.properties, same packs where applicable) back to 1.26.32.2 resolves the issue entirely — RSS settles at ~13MB (packless server) / ~687MB (server with packs), both stable long-term.

Impact

Both of our Bedrock servers became completely unable to start after updating to this build, on a host that had run every prior version without issue. Had to roll back to 1.26.32.2 to restore service.