Crash on save on Windows after long playtime, pure virtual method called

[DonBellozi]

Crash on save on Windows after long playtime, not reproducible on Linux

Description

RTTR crashes on Windows during a save operation with the following runtime error:

pure virtual method called
terminate called without an active exception

The same savegame behaves differently on Linux: it loads and saves correctly.
After re-saving the game on Linux and copying the savefile back to Windows, the crash no longer occurs (at least so far).

This suggests platform-dependent behavior, possibly related to savegame serialization or object lifetime handling.

---

Environment

Windows (crash occurs)

• OS: Windows 11 Pro (also reproduced on Windows 10)
• RTTR version: v20260114-5452ee9
• Architectures tested: x86_64 and i386
• CPU: Intel Core i11 (11th gen)
• GPU: NVIDIA GeForce RTX 4070
• Graphics backend: SDL2 OpenGL (OpenGL 4.6 supported)
• Audio backend: SDL2_mixer
• Install path: E:\Settlers2
• User data path:
  C:\Users\Bell®\Saved Games\Return To The Roots

Linux (no crash observed)

• OS: Ubuntu 24.04.3
• RTTR version: v20260114-5452ee9
• Runtime: VMware® Workstation 17 Pro
  Version 17.6.4 (build-24832109)

---

Steps to reproduce (Windows)

1. Start RTTR on Windows
2. Load the attached savegame
3. Play the game for a longer period of time
4. Attempt to save the game manually
5. Game crashes with:

pure virtual method called
terminate called without an active exception

---

Steps to reproduce (Linux)

1. Start RTTR on Linux
2. Load the same savegame
3. Play for some time
4. Save the game

Result: save succeeds, no crash.

---

Additional timing details

• The crash occurred after approximately 20 hours and 31 minutes of gameplay on the same map
• Before the crash:
• Autosave was enabled with a 10-minute interval
• Autosave worked reliably for the entire session (≈120 autosaves)
• The crash happened during a manual save attempt

This points to a long-running session / accumulated state issue rather than a general save failure.

---

Workaround / Additional findings

• Saving the game on Linux and copying the newly created savefile back to Windows prevents the crash (so far).
• Linux appears to re-serialize the game state in a way that avoids triggering the issue on Windows.

---

Expected behavior

Saving the game should not crash on any platform.

Actual behavior

• Windows: crash during save
• Linux: save succeeds

---

Notes / Hypothesis

• The error looks like a C++ runtime issue (pure virtual method called), possibly caused by invalid object lifetime or use-after-free.
• The issue appears platform-specific and may be related to:
• savegame serialization/deserialization
• long-running sessions with accumulated game state
• undefined behavior manifesting differently on Windows vs Linux (compiler / STL / memory layout differences)

---

Attachments

• Original savegame file (before crash)
• Savegame file re-saved on Linux
• Full Windows console log

LOGS.zip

[Flamefire]

Can you reproduce this by loading the replay of the crashing game and saving it at the end of the replay? "Play the game for a longer period of time" is rather vague and hard to see if the bug is fixed or just doesn't appear yet or anymore. And playing the game for over 20 hours to find the bug is also not feasible.

[DonBellozi]

Yes, the crash is reproducible via replay.

On Windows:

• Loading the replay of the crashing game
• Fast-forwarding it to the end
• Saving the game immediately after the replay finishes

reliably triggers the same crash:

pure virtual method called
terminate called without an active exception

This reproduces the issue without manual gameplay and does not require playing for 20+ hours.

If needed, I can attach the replay file used for reproduction.

2026-01-17_02-54-48.zip

[Flamefire]

That replay helps. The issue is a use-after-free which is likely caused by the destruction of the military building at 108,132

For some reason the defending soldier at the fortress at 108,122 seems to have waited for an attacker that is returning home. And after it arrives home the point to it in the defender is dangling causing the crash.

What is also weird is that the stored position of the defender of 108,122 is 108,132 and the building at 117,126 seems also involved.

The replay is too late to show why that situation appears. Do you have a longer replay, preferably from shortly before the building at 108,132 was destroyed? Or somewhere around the time the defender at 108,122 showed up

[DonBellozi]

Thanks for the explanation.

I tried to enable a local debug overlay to display map tile coordinates, but I couldn’t find a way to enable it in my build.

I believe I have visually identified the locations you mentioned (108,132 / 108,122 / 117,126) on the map, but I’d like to make sure I’m looking at the correct tiles.

Is there a recommended way to enable map tile coordinate display in-game or during replay playback?

[Flamefire]

You can play F3 to enable the overlay. There you can also enter the coordinates and jump to them directly.

[DonBellozi]

Thanks for the explanation.

I was able to enable coordinate display using F3 – thank you for that.
Yes, I was indeed looking at the correct locations on the map.

I can also provide some additional context about what likely caused this state. Unfortunately, the initial event happened several hours of gameplay before the crash, and I no longer have saves or replays from that exact time.

What happened (as far as I can reconstruct it):

• There was an enemy attack on the fortress at (108,122).
• Multiple attackers were queued to fight.
• During the active attack, I removed the road leading to the fortress (approximately from 108,123 to 109,125, crossing the river).
• After removing the road, one attacker got stuck on tile 109,123 or 109,124 and never proceeded.
• The defending soldier killed the previous attacker, but the next one never arrived.
• All remaining attackers queued around the fortress flag and were eventually killed by my soldiers from nearby fortresses.
• The “stuck” attacker remained standing in place for several hours of gameplay.
• Rebuilding the road later did not resolve the situation.
• After a later crash and reload, the stuck attacker was no longer visible, but the defending soldier remained in a stuck state and is still standing there.

This event occurred roughly 3–4 hours (or possibly more) before the crash that happens when saving the game.

An additional observation: after my soldiers killed all non-stuck attackers, civilian units (carriers transporting goods) were able to freely pass through the former combat area, and I was even able to build a catapult nearby. This suggests that, from the game logic perspective, the area was no longer considered to be under active combat, even though one attacker and one defender were effectively stuck in an invalid state.

Additionally, I have occasionally observed similar situations where an attacker appears to get “stuck” during an attack on one of my fortresses. In those cases, I either did not pay much attention because reloading from an autosave allowed the game to continue normally, or the issue did not visibly affect further gameplay. Because of that, I cannot say for sure whether those cases were internally identical, but visually the behavior looked similar (a single attacker not progressing while others queue or combat does not advance).

I have also occasionally noticed similar “stuck attacker” behavior while defending ports.

Unfortunately, I no longer have saves or replays from the moment when this state was first created. However, if it would help, I can try to deliberately reproduce this scenario with replay recording enabled.

[Flamefire]

Ok, the issue is certainly caused by removing the road: When the current attacker is killed the next waiting one is called. The stuck attacker was waiting and is now considered to be walking to the defender. However there is no path anymore. We return this information but ignore it. So the defender will keep on waiting and the attacker won't start walking.

The road must have been from the building flag too where the attacker was waiting or that position wouldn't have been considered valid for waiting.

It would be great if you can recreate the situation and provide a replay for me to verify my fix works. But I'm quite sure it does.

[DonBellozi]

Thanks, that explanation matches what I observed.

I’ve now recreated the same conditions (attack in progress + removing the road to the fortress), so I can provide additional evidence.

Would a video recording of the situation be sufficient for you, or do you specifically need a replay file to verify the fix?

If a replay is required: I’m not sure how to intentionally record a replay in RTTR. Could you please tell me how to enable replay recording?

[Flamefire]

Yes I need the replay as only that captures the exact flow of events.
For any game you play a replay is automatically stored. So you don't need to enable anything, the replay will be there

[DonBellozi]

It wasn’t easy, but I managed to reproduce the issue and record a replay that contains the problem. I’m attaching it here.

One additional note: in this reproduction there is a small creek/stream acting as an obstacle, but I’ve also seen a similar “stuck attacker” behavior near ports, where there is no creek/stream involved. In those cases the enemy soldier can also freeze/stay stuck in place in a similar way.

2026-01-18_15-08-08.zip

[Flamefire]

Ok, just for reference this is where the issue appears:

I'll see if I can capture a mocked test for this as my fix had a subtle issue