"Mountain 3 crash" (speedrun community) – investigation 2026-11-08

Short version: Mountain 3 = t1l5m003 (world 5, chapter 3). Its boulder spawner (RollingBoulderMountain) can end while a boulder it spawned is still alive. When that boulder finishes its path, it decrements parent.v13 of the dead spawner. That write (-= 1.0, i.e. -0x1000) goes into freed or reused memory (use after free). If it hits a header of the game's local heap, a later FreeLocalMem crashes. That matches the community crash dump. The stale write is verified in game. A full crash was not reproduced. A one-word level-data patch removes the stale write (verified in game).

Evidence from the community

DebugDiag dump (English exe, 2000-10-17): access violation writing 0x0000340d at groove+0x1ad52 = VA 0x41AD52, thread 0, Argonaut name FreeLocalMem.
English 0x41AD10..0x41AD89 is byte-identical to German FUN_0041ada0 (only the rel32 of the "ITS NOT USED! %08x" debug printf differs). Crash instruction = German 0x41ADE2 mov [eax+4], esi.
The local heap (FUN_0041af00 init, FUN_0041ae20 alloc, FUN_0041ada0 free) holds blocks with a 12-byte header {next, prev, u16 size (dwords), u16 used}. The blocks are contiguous (next == hdr + (size+3)*4). On free, the routine merges with the next block if next.used == 0, then does next->next->prev = hdr. The crash means the header after the freed block had used == 0 and next == 0x3409. 0x3409 is not 4-aligned, so it can't be a real block pointer. The heap metadata was corrupted earlier, and the free only shows it.
Clips: index.mp4 is in a snowy canyon with a pushable boulder (red X), wall shards (SmashWallShrapnel), a ruby-idol pickup (HUD), and a crash at the cave about 6 s later. index2.mp4 is the Kronk ice race (KronkOnIceDoor/KronkOnIce, same WAD): black screen about 2 s after the race starts. Both are in t1l5m003. Our boot to (74.6, 14.8, 6.3) shows the same canyon and boulder as clip 1, so clip 1 is most likely the #47 push-boulder section (hypothesis, based on what the scenes look like).
Side note: the heap is operator_new(0x200000) but is initialised with size 0x800000 into a u16 field, so it is really 0xFFFD dwords (≈256 KB). Mountain 3 uses about 88 KB of it, so the heap is not exhausted. No leak was seen: block count stayed stable over minutes.

The bug (strat code of unit 1 of t1l5m003, verified by disassembly)

RollingBoulderMountain (6 MAP instances, params v0..v9). v13 is set to 0 and never incremented anywhere. The only other access is the boulder's parent.v13 -= 1.0 (pushParentVarAddr v13; dec) in L_0574, which runs when the boulder ends its path or falls:

spawner:  ... spawn loop (L_0c24: spawn<7,31,4,0x14c000,0>(…RollingBoulderForMountain)) ...
          freezeOffCamera 1
L_0d90:   pushVar v13 / pushShort 0 / eq / jzYield L_0d90 / end      ; ends at once when v13 == 0
boulder:  L_0574: parent.v13 -= 1.0 ; ... ; remove

With v1 == 0 (instances #17 and #35) or v4 != 0 (#22 and #47, the pushable "red X" boulders, which wait to be charged), the spawner spawns one boulder and ends in the same frame (v13 is still 0).
Instances #1 and #27 (v1 = 8.3 / 8.75) loop: a boulder about every 8–10 s, until the player is near the path start. They end the same way if no boulder has died yet when the loop exits.
Strat removal (strat update loop FUN_0054c4a0) frees the var block (+0xF4) and the collision block (+0xC0) and puts the struct on the free list (LIFO). It does not clear the children's +0xC parent pointers. The parent opcodes (0x553750/0x553770/ 0x553a40) have no check.
So the boulder's write goes to deadSpawner.vars + 0x34: either memory of the freed var block (now part of a free block or of another allocation, possibly a block header), or, if the struct was already reused, v13 of another strat. For a boulder, v13 is its sound address (v13 = sound:4, used by playSoundChannel).
"Predictable intervals" (runner's guess) fits: the stale writes happen a fixed time after you pass a spawner, or after you push a boulder, when that boulder reaches the end of its path. Whether a write hurts depends on the heap layout at that moment, so it depends on timing. It is not deterministic across runs.

In-game verification (apptest, Xvfb :26, sessions `mtn3-*`)

Tooling (throwaway, see notes/dev/mountain3-diag/): a test-only mod Mtn3DiagMod (loaded through APPTEST_CP + -Dllamamod.extraMods). It installs a code cave (cave.asm, nasm) that replaces the pushParentVarAddr and popParentVar handlers. They log every access, flag stale ones (parent +0xEC == 0, i.e. removed) together with the block that the target address falls in, and walk the whole heap on every alloc and free (next/prev/used consistency). rd.py reads the log by attaching winedbg for a moment (stdin script attach/x/detach; works under ptrace_scope 1). apptest.py in the agent copy got an env switch APPTEST_IGNORE_WINEDBG so the short attach is not taken for a crash (not copied back). A gdb-over-winedbg monitor with breakpoints was too slow: the game froze.

Boot-to-level start=29.5, 14, 23.2, 180 @ 5/3 (next to spawners #1 and #17), no input, 70–85 s:

	runs	runs with a stale write	heap anomalies	crash
original WAD	6 (1 manual + 5)	5	0	0
level fix (below)	3	0	0	0

Every stale record was the same and deterministic for this start (logged by the cave): RollingBoulderForMountain → parent RollingBoulderMountain (struct +0xEC == 0, removed), v13, target = freed var block + 0x34. At the time of the write this address was inside a used 16-dword block (a 0x40000 collision block, most likely the next boulder's), at offset +0x40 from its header, which is 12 bytes before the next block header. In this layout it corrupts collision data (u16 fields +0x34/+0x36 become 0xF000/0xFFFF), not the heap. Any other layout (other timing, other route, other spawns in between, e.g. an 11-dword allocation such as a 0x28000 pickup's collision block puts a remainder header's size/used word exactly there) turns the same write into header corruption. Not verified: a crash caused by this write. No natural run crashed, and the real runner route (from the chapter start at full speed, pushing #22/#47, then the race) could not be driven reliably by key scripts (the push needs speed and alignment; several attempts missed). Also seen in game: strat structs are recycled LIFO (the dead spawner's struct was later reused by a boulder).

Other checks in this WAD: every collisionOn user is spawned or placed with collision type flags (no typeFlags 0 + collisionOn case like in the arena), and all extra operands are 0. Other parent-variable writers (KronkOnIcePickup → parent.v7, CheckPointHead, RubyIdolStatue, AxeGuardAxe) have parents that do not end while they live, as far as the code shows. That was checked by reading the code only; the cave saw no stale access from them.

Side finding (not part of the crash): boot-to-level start=28.5, 10.5, 22.5, 0 @ 5/3 passes the floor check, but the game crashes while loading (page fault read 0x00000002 at 0x405527, floor/ tile lookup in FUN_004054c0). Out of scope here.

Fix / avoidance

Level data (tested): in RollingBoulderMountain, change pushShort 0 before eq to pushShort 0.5 (word 0x00000044 → 0x08000044, the only match of the 6-word pattern 0x1002f 0xd0004 0x44 0x4e 0xfffc0012 0xb4, file offset 0x4a0a27 in the German t1l5m003.wad). v13 only takes whole numbers (0, -1, -2 …), so the spawner never ends. It stays frozen off camera and costs nothing, and every boulder writes into a live spawner. The boulders still roll (in-game: 6–7 normal parent writes per run, 0 stale). notes/dev/mountain3-diag/wadfix.py IN OUT. The English CD's WAD is not checked; the patch looks for the pattern and refuses if it isn't unique.
Exe (general, untested): let removal (+0xE8 & 4 path) clear +0xC of all strats whose parent is the removed one (pool DAT_006d9dc0, stride 0x154), and let the parent opcodes redirect a NULL or removed parent to a dummy dword. This also covers similar bugs in other levels.
Runners (hypothesis): there's no reliable avoidance. The write happens when the boulders of #17 and #35 (spawned when you pass their trigger spots) and the pushed boulders #22 and #47 reach the end of their path. Not pushing #22/#47 removes two of the four guaranteed stale writes, if the route allows that.

Diag tooling notes: the files in notes/dev/mountain3-diag/ are as used, with absolute paths of the agent job dir. The mod writes addresses.txt and expects cave_<fix>_<CAVE>_<DATA>.bin (nasm -f bin -DCAVE=0x6ef0e0 -DDATA=0x70f010 -DFIX=0 cave.asm; these addresses are valid with boot-to-level + mtn3-diag on the German exe). This is only for the German exe; nothing is registered in the app.

Discord answer (draft)

We looked into the Mountain 3 crash. Your dump crashes in the game's own memory manager (FreeLocalMem, writing to 0x340d). That is the symptom: its bookkeeping was overwritten earlier. Verified: in Mountain 3 the rolling-boulder spawner can delete itself while its boulder is still rolling. When that boulder reaches the end of its path (or falls off), it writes into the spawner's memory, which has already been freed and reused. We saw this write in the game with a debug build, and a one-value level patch makes it go away. Not verified yet: that this exact write causes your crash. We never got the game to crash. Where the write lands depends on what else is in memory at that moment, so it breaks things only sometimes, and the crash can come seconds later somewhere else (e.g. in the Kronk race). That would explain why it's Mountain 3 only, at different spots, without an error message, and "every so often" around boulders. The likely triggers are the one-shot boulders near the start/top of the slope and the two red-X push boulders. We'll probably ship the fix in LlamaMod.

10 KiB Raw Blame History Unescape Escape