Arma Reforger — Engine crash: resource/entity streaming use-after-free under network replication

Summary

Both the dedicated server and clients intermittently hard-crash with zero script call stack — a pure native access violation inside the engine, not inside any mod or scenario script. The crash consistently fires either:

- server-side, inside WORLD: UpdateEntities → RPL: ProcessNetToGame (i.e. while the replication layer is turning networked data into live entities), or

- client-side, while a resource (material/mesh) is loading mid-entity-spawn RESOURCESMATERIAL load logged immediately before the crash).

It is not tied to any specific mod, prefab, or item — the faulting resource is different every time, and several of the crashing assets below are vanilla base-game content (a base-game medical kit, a vanilla vehicle-debris particle, a vanilla wreck material), ruling out a bad third-party asset as the cause. It correlates strongly with entity-spawn/replication churn — heavy base-building, loadout/arsenal cycling, vehicle spawning, or player joins happening in a tight window — and with higher player counts, but it is not deterministic: the same action (e.g. spawning a specific vehicle) can succeed cleanly dozens of times before triggering the crash once.

This matches the community-documented "entity/resource streaming use-after-free" pattern already tracked on the feedback tracker under tickets in the T176563 / T193059 / T196092 family (garbage-pointer access violation, no script frames, reported since ~v1.4 across both modded and vanilla setups, all hardware vendors). We are still seeing it on 1.8.0.10.

Environment

- Game version at time of these crashes: 1.7.0.54 and 1.8.0.10 (both — bug persists across the update)

- Server: dedicated Linux server /home/reforger/ArmaReforgerServer), 120+ mod modded Conflict server, typically 60–290 total connections, 100–125 concurrent players at crash time

- Client crashes reproduced on multiple independent machines/GPU vendors: NVIDIA RTX 5070 Ti (11GB, well under VRAM budget at crash time), NVIDIA GTX 970 (4GB, at/over VRAM budget at crash time)

- Server launch params: maxFPS 120 freezeCheck 120 nwkResolution 150 playerLimits "US:64,USSR:64,FIA:0"

Evidence — confirmed instances (dump + report GUIDs for cross-reference)

All of the below share the identical signature: ENGINE (E): Application crashed!(server) or *Unhandled exception / Access violation** (client), with no script stack whatsoever — the crash report's stack trace section is either completely blank ("Reason: Unknown") or shows only raw native module addresses with no resolvable script frames.

| | Date/time (local) | Side | Player count | Dump file | Crash Report GUID | Notes |

|---|---|---|---|---|---|---|

| 1 | 2026-08-16 14:15:05 | Server | 124 connected / 290 total | /tmp/021aaa12-eaf5-40e8-0a559aab-a7687631.dmp | f16c8d76-cfe7-492f-9de7-4b36784de877 | Fired in ProcessNetToGame immediately after routine events (player death, a Game Master exiting editor mode, a player join finishing) — no unusual action at the crash instant itself |

| 2 | 2026-08-03 22:44:49 | Server | ~75 | /tmp/83b5349b-5e69-4af7-ebba3488-44f36b6f.dmp | 4f5b6dc3-c5c2-4872-8ade-c36d5037ea87 | Preceded by a heavy loadout/arsenal-cycling burst (dozens of gear item spawns in the seconds before) |

| 3 | 2026-08-03 13:40:51 | Server | ~63 | 71256b33-4e0a-4579-69c14c90-1236f04e.dmp (56 KB) | b6a4f781-b140-4a93-bf48-7ec2c3d4a2b5 | Preceded by a vehicle spawn ~4.7s earlier; that same vehicle prefab had spawned 8 other times cleanly in the preceding 27 minutes — not deterministic on that action |

| 4 | 2026-08-15 21:04:34 | Server | — | /tmp/d9fdbe83-dd4a-4f62-0d03209b-862d5020.dmp | — | Fired ~0.4s after a player opened the in-editor building mode |

| 5 | 2026-08-03 18:59:06 | Client | — | ArmaReforgerSteam_2026-08-03_18-59-06.mdmp | — | Access violation. Illegal read at 0x1e000000000. Console log shows the crash landed midMATERIAL: Material load for a vanilla base-game medical kit MedicalKit_01_US.emat) during an entity spawn. GPU: RTX 5070 Ti, VRAM 9180/10858 MB (well under budget — not an OOM condition) |

| 6 | 2026-08-03 18:05:39 | Client | — | ArmaReforgerSteam_2026-08-03_18-05-39.mdmp (166 KB) | — | Access violation. Illegal write at 0x7ff6baafc818. GPU: GTX 970, VRAM 3750/3177 MB (over budget at crash time — see note below). The item mid-load 4.4 seconds prior had already loaded 3 other times that same session with no issue |

Additional prior instances (July 2026, same signature, same engine, both vanilla and modded prefabs implicated including a vanilla vehicle-wreck material and a vanilla ammunition material) were captured and reported separately; we can supply those dump GUIDs again on request if the originals are no longer on file.

Pattern analysis

1. No script involvement. In every case the crash/stack trace is either empty or contains only raw addresses inside the game's own native module — never a Scripts/Game/... frame. This rules out mod scripts, Enfusion scripting layer, and scenario logic as the direct cause.

2. Garbage/invalid pointer, not out-of-memory. Where an address is reported, it's either a clearly invalid pointer 0x1e000000000) or a small dump size (53–166 KB) with healthy memory/FPS the frame before — consistent with a use-after-free (dereferencing memory that was already released) rather than memory exhaustion. One instance (case 6) did coincide with a GPU near its VRAM budget, suggesting VRAM pressure can be a contributing/amplifying factor on weaker hardware, but it is not the root cause — case 5 crashed on a card with 15%+ VRAM headroom.

3. Consistently correlates with entity-spawn / replication churn, not with any single item. Every case fired within seconds of heavy entity creation activity: base-building placement, loadout/arsenal item cycling, vehicle spawning, or a burst of player joins — but the specific prefab loading at the crash instant is different every time, and several are stock/vanilla assets, not third-party content.

4. Not deterministic. The same trigger action (spawning the same vehicle, loading the same optic/material) succeeds cleanly the overwhelming majority of the time and only occasionally crashes — a hallmark of a race condition or a freed-object edge case rather than a straightforward null pointer or missing-asset bug.

5. Reproduces on both dedicated server and client, and across at least two different GPU vendors — this is engine/replication-layer behavior, not a driver or hardware-specific issue.

6. Persists across the 1.8.0.10 update. We re-tested after the 1.8.0.10 stable release (which did ship several unrelated crash/memory-leak fixes) and the same signature is still occurring.

Impact

On a busy server (100+ concurrent players, heavy base-building/arsenal activity, which is common for large modded Conflict servers) this fires roughly every few hours of active play, each time force-disconnecting the entire playerbase and requiring a manual restart. It is currently the single largest source of unplanned downtime for this server.

Attachments available on request

Full .mdmp memory dumps, console.log, error.log, and crash.log for every instance listed above are retained locally and can be attached to the tracker submission if useful for reproduction/analysis.