Devlog · Engine & Netcode
A newly documented Unreal Engine 5.8 failure can erase the evidence after a Linux process crashes. For an MMO, crash reporting cannot be the only witness.
The most important Unreal Engine development this week is a failure in the failure path itself.
On September 16, Epic documented a UE 5.8 Linux condition in which a crashing process can exhaust the small emergency allocator used to generate its own crash report. The result can be a crash directory with context files, a zero-byte engine log, no Crash Report Client launch, and no uploaded report.
For a PC-first MMO with Linux backend infrastructure, that changes the production question. It is not enough to ask whether a dedicated server recovers from a crash. We must also prove that the studio receives enough independent evidence to explain it.
UE-397073 describes the mechanism precisely. During Linux crash handling, Unreal switches to FPlatformMallocCrash, an emergency allocator with a two-megabyte large-memory pool. Its Free() operation is intentionally inert because ordinary allocator state may no longer be trustworthy.
Crash reporting can then consume that limited pool in several ways. Copying the engine log uses a scratch buffer of up to one megabyte. Capturing call stacks for every thread creates data that grows with thread count. The crash-context XML is copied rather than moved, and additional plugins can make that context larger.
If the pool is exhausted, the reporting path fails. Epic's reproduction produced an empty copied log, never launched Crash Report Client, and uploaded nothing. The issue affects UE 5.8 and remains unresolved; Epic currently targets 5.8.4 for the correction.
Epic lists unix.CaptureAllThreadStacksOnCrash=false as a workaround that usually restores reporting. That trade is significant. It can recover the crash artifact by discarding one of its most useful components: the stacks of threads other than the crashing thread.
This is a diagnostic lever, not an observability strategy.
Epic reproduced UE-397073 in a Linux editor build, not in a COGHEIM-style dedicated server. We should not claim that the dedicated server is confirmed affected.
The underlying conditions nevertheless overlap with MMO infrastructure closely enough to demand a test: Linux platform crash handling, many active threads, extensive logging, and a plugin-rich process. A server may also run for far longer than an editor session, making a missing report especially costly when a rare failure finally appears.
COGHEIM should therefore treat Unreal's crash report as one layer, not the sole source of truth.
| Evidence | Independent source |
|---|---|
| Process termination and exit code | Container runtime, service manager, or watchdog |
| stdout and stderr | Host-level collector outside the Unreal process |
| Engine context and minidump | Unreal crash-reporting path |
| Core dump and kernel evidence | Operating system |
| Match, shard, and player correlation | Backend trace or session identifier |
| Recovery behavior | Orchestrator health checks and restart events |
The acceptance test should be intentionally unpleasant. Force a controlled crash in a packaged Linux server running representative plugins, thread counts, and log volume. Confirm that every expected artifact is nonempty, that collection succeeds, and that a trace identifier connects the process failure to the affected shard or session.
Repeat the test with all-thread capture enabled and disabled. A workaround is only useful when we know exactly what evidence it removes.
A second issue, UE-364106, concerns memory retained while editing Nanite Landscapes. Epic found that bulk data generated for Landscape proxy Nanite meshes could remain allocated after the level was unloaded.
The defect is influenced by Derived Data Cache state. It can appear on the first mesh build or after sculpting forces regeneration, which means a warm, short editor test can miss it. Epic marked the issue fixed on September 17 and identified fix commit 53777351, but the public ticket does not name a target release.
COGHEIM inference: This is an editor-stability issue rather than evidence of a shipping-client leak. It still matters because long World Partition authoring sessions are part of production capacity. Memory that grows after repeated landscape rebuilds and unloads can slow iteration, produce misleading "out of memory" diagnoses, and make the workstation — not the content — the apparent culprit.
Our regression case should follow the stateful path Epic describes: start with a clean DDC, rebuild representative Landscape Streaming Proxies, unload the level, and inspect an Unreal Insights memory trace. Then repeat with a warm cache and after sculpt modifications. The important result is whether memory returns after the world is unloaded, not whether one rebuild completes.
Epic also resolved UE-395897 on September 15. The issue produces motion-blur artifacts in Epic's MetaHuman Crowd demonstration and may be a broader interaction between motion vectors and teleporting actors. Epic lists UE 5.8.3 as affected and targets the fix for 5.9.
That does not prove COGHEIM's crowd systems will show the artifact. It does identify a sharp test case.
COGHEIM inference: Large-world population systems often reposition entities, switch representations, or move agents into relevance. Any path that appears as a teleport to the renderer deserves inspection with motion blur enabled. Our test should include camera movement through dense populations, explicit actor teleports, and representation transitions while examining velocity buffers frame by frame.
The wrong response would be to disable motion blur globally before reproducing the problem. The useful response is to identify which transition creates invalid motion history and determine whether the failure is visible in COGHEIM's actual camera and movement model.
This week we are making crash evidence a tested server capability, not an assumption:
unix.CaptureAllThreadStacksOnCrash=false in staging, understanding that it sacrifices per-thread call stacks.The common lesson is hidden state. A crash system can consume its own emergency memory. A landscape can appear unloaded while generated bulk data remains. A crowd actor can reach the right location while carrying the wrong motion history.
UE-397073 · Linux Crash Reporter can fail when generating the report · opened September 16, 2026UE-364106 · Possible leak using Nanite meshes for Landscape · resolved September 17, 2026UE-395897 · Motion-blur artifacting in MetaHuman Crowd demo · resolved September 15, 2026Reliable production comes from testing the state behind the visible result.
← All Devlog Posts