Fix two server crashes: Team Objective stack overflow under --desync-patch, access violation in the combat hooks

[wiseLlama0]

Two crash fixes found while running community servers on v1.0.0-RC2. Based on implement-rust-hooks-maximal at the RC2 tag

1. Stack overflow on Team Objective maps with --desync-patch

Symptom. With --desync-patch on, loading a Team Objective map ends in EXCEPTION_STACK_OVERFLOW about five seconds later. Repro on an empty server: RCON servertravel To_DarkForest. With the patch off, the same travel works and the match reaches InProgress. This is a known issue with TO maps in RC1

Cause. The ProcessEvent hook in resolvers/desync.rs already drops ClientSetCameraMode ("event spam (deadlock)"), but it is compiled out with { || false }, so the block never runs.

Fix.

• The hook is active whenever --desync-patch is given. Every event now passes the detour, so the ClientSetCameraMode check uses the FName comparison index; the string conversion happens once per distinct function and is cached per thread. The per-event Class::Function debug log is dropped for the same reason.
• A per-thread depth guard in the same hook: beyond 300 nested calls (UE's own script limit is 120), the event is dropped and logged as Class::Function at error level instead of overflowing the stack. It never fired once ClientSetCameraMode was blocked; it's a safety net for the next loop of this kind.

Result. With the block active, the TO map loaded, the plugin logged four ClientSetCameraMode blocked lines, the match reached InProgress, and two players then played a TO match on it. Travel back to an FFA map worked.

There may be more crashes that come up in Team Objective maps, but in order to fix those we need to hit them by actually playing the Team Objective maps, which this allows.

2. Access violation in the damage and kill hooks

Symptom. ACCESS VIOLATION ... READ addr=0x100000440 at the first instruction of TArray<u16>::copy_to_string, reached from the combat resolvers in resolvers/gameplay.rs. One server logged 26+ crash dumps with it between 2026-09-22 and 09-28, and a second server crashed with it too. The same fault crashed a client running the released RC2 DLL after a kill credited to an actor without a player state (a mod's damage volume).

Cause. The resolvers name the instigator, causer and victim of every damage and kill event by following pointers to an APlayerState and copying PlayerNamePrivate:

• The bad value is 0x0000000100000100, from TBLCharacter.LastPlayerState, which the plugin declares as a raw pointer. Read as two i32s it is 0x100 and 1, which looks like a TWeakObjectPtr (index, serial number) rather than an address. It is aligned and in the user-mode range, so nothing rejected it.
• copy_to_string copied the text through ReadProcessMemory but read the length directly. With PlayerNamePrivate at 0x338 and the length at +8, that read faults at exactly 0x100000440. A dangling pointer to a destroyed object could fail the same way.
• Related: object_inherits_from matched class names by substring, so "Character" also accepted classes such as CharacterDeathcam_C, which were then read through the ATBLCharacter layout. LastPlayerState was read from any "Character", although it exists only on ATBLCharacter.

Fix.

• First commit: exact class-name matching, a bounded superclass walk, and a cheap pointer pre-check. This alone does not stop the crash, because the bad value passes the pre-check.
• Second commit, which stops it:
  • ue::try_read<T>, a copy through ReadProcessMemory that fails instead of faulting.
  • FString::copy_to_string reads its header that way and rejects a negative length, a length above capacity, or one above 2^20 code units.
  • FUObjectArray::is_live: the object's InternalIndex, read safely, must name a GUObjectArray slot that holds this pointer and is neither pending kill nor unreachable (the check IsValid makes).
  • The combat resolvers require is_live for every actor, controller, player state and damage-source pointer before reading it, read LastPlayerState only on a real TBLCharacter, and log a warning naming the field when they reject one.

Result. On a server under load (29 minutes, 7 joins, 1,868 damage events, 321 kills) the plugin logged ignoring PlayerState 0x100000100 from TBLCharacter.LastPlayerState: not a live object twice and kept running. That is the value that crashed it before.

Testing

• cargo build --release and cargo test --release pass. Each commit compiles on its own (cargo check) with the same 9 warnings as RC2.
• These changes have run on our servers since 2026-09-22 (TO fix, class-name matching) and 2026-09-30 (liveness checks), inside fork builds that also carry unrelated changes (diagnostic flags, server-mod spawning, chat logging). In this branch, gameplay.rs and src/ue/ are identical to what ran apart from comments. The ProcessEvent hook takes the same path under --desync-patch, without our diagnostic flags. This exact build has not been run on a server yet, which is why the PR is a draft.

Not included

• LastPlayerState as a weak pointer: declaring it as TWeakObjectPtr and resolving it through GUObjectArray would give those events a name instead of a warning. Not done yet.
• Diagnostic flags we used to find the TO loop (--log-events, --block-events). Happy to send them separately if they're wanted.

🤖 Generated with Claude Code