Full client hang (UI layout recursion) when the step list is shown on Midnight leveling guides (12.0.5)

[InfiniteLoopAlchemist]

Summary

With a RestedXP leveling guide active and the bottom step list shown, the WoW client hard-hangs after roughly 3 to 5 minutes of normal play and must be force-quit. It is not a crash and not a memory leak. One CPU core is pinned at 100% while system memory stays flat, and a native sampler shows the client stuck tens of thousands of frames deep inside the UI layout/anchor resolution code, entered from the per-frame render loop. Hiding the step list eliminates the hang completely.

Environment

• WoW Retail 12.0.5 (build 12.0.5.67823)
• macOS 26.5, Apple M1 Max, 32 GB
• RXPGuides v4.10.12
• Active guide: "ce) Voidstorm Route 3 (H)" in group "RestedXP Midnight" (Horde character), around step 31

Steps to reproduce

1. Load the RestedXP Midnight guide "ce) Voidstorm Route 3 (H)" (Horde) and level normally. (Not a starting-zone guide; observed mid-route around step 31.)
2. Ensure Settings > Show step list is enabled (the bottom frame that lists all steps of the current guide).
3. Play for about 3 to 5 minutes.
4. The client hangs completely (full freeze, must force-quit).

Toggling Show step list OFF prevents the hang indefinitely (tested 4+ minutes with no freeze). Toggling it back ON reproduces the hang within about 3 minutes. This is consistent and repeatable.

What it is NOT (evidence)

• Not a memory leak: external process monitor showed resident memory flat at ~4.5 GB of 32 GB through the hang; the addon's own Lua memory plateaued around 90 MB.
• Not a crash: no kernel panic was written; the OS itself stayed responsive during the hang (background processes kept running). The game process alone was unresponsive.
• Not an event storm: QUEST_LOG_UPDATE / UNIT_QUEST_LOG_CHANGED fire rates were measured at zero during the lead-up; zero Lua errors captured.
• Not a guide-chain (#next) issue and not a SetPoint anchor cycle: a frame-level cycle check on the step frames did not find a circular SetPoint.

What it IS (evidence)

• At the moment of the hang, one CPU core jumps to and stays pinned at ~100% (single-threaded), while the other cores idle. Classic single-thread infinite recursion.
• A native sample of the hung process shows a stack roughly 52,000 frames deep, dominated by two alternating addresses in the WoW client binary, entered from the normal per-frame UI update/layout path (not from an event handler and not from the quest-log scan). This is the signature of the layout engine recursing while resolving a frame's size/position dependency that never terminates.
• Bisected to the step list: the recursion only occurs when the bottom step-list frame (BottomFrame) is shown. Disabling it removes the trigger entirely.

Likely area

The bottom step-list frame layout in GuideWindow.lua (the BottomFrame / ScrollChild step-frame pool and the current-step-frame sizing/anchoring). On certain guides/steps the step-list frames appear to create a size or anchor dependency the layout engine cannot resolve, causing an unbounded layout recursion. It is data/step dependent (specific to the guides being run), which is why it does not reproduce on every guide.

Suggested investigation

• Reproduce with the step list shown on the affected guide ("ce) Voidstorm Route 3 (H)", RestedXP Midnight), then inspect the BottomFrame step-frame sizing/anchoring for a frame whose height or anchor depends (directly or transitively) on a frame that depends back on it.
• Check any per-step frame height calculation that reads a parent or sibling height while that parent/sibling height is being derived from it.

Workaround for affected users

Settings > Show step list = OFF (then /reload). The current-step guide still functions normally; only the upcoming-steps list is hidden.

[InfiniteLoopAlchemist]

Additional debugging data from a contributor (macOS, Retail 12.0.5), in case it helps localize this. The client binary is stripped so I only have offsets, but the signatures were consistent across many captures.

1. The hang is a single-thread recursion inside the client's UI layout pass, entered from the per-frame render loop (not from an event handler and not from the quest-log scan). One core pegs at 100%, memory stays flat, no crash or panic.

2. It is triggered specifically by the bottom step-list rows (the BottomFrame / ScrollChild step-frame pool in GuideWindow.lua). With the step list hidden it never occurs; turning it back on reproduces it.

3. Concrete lead on the row layout. Each step row's FontString (frame.text) is anchored on all four sides: TOPLEFT to the row and BOTTOMRIGHT to frame.number's BOTTOMLEFT (GuideWindow.lua around 1877-1878), while the same row's height is set on every relayout from that FontString's measured height via frame:SetHeight(math.ceil(frame.text:GetStringHeight() + 8)) (around line 2092 / 2004). Since frame.number is anchored to the row's bottom (around line 1859), the FontString's bottom edge depends on the row height and the row height depends on the FontString, a self-referential size dependency. The always-shown current-step frame does not hang, and it anchors its element text width-only (TOPLEFT + RIGHT, around line 1138-1141), leaving height natural, which is the safe pattern.

4. As an experiment I changed only the row FontString to width-only anchoring (RIGHT to frame.number LEFT instead of BOTTOMRIGHT to BOTTOMLEFT). That eliminated the specific infinite-recursion signature that had dominated every capture, but on large guides it left a heavy finite layout cost and noticeably higher memory. That points to a second, separate cost: every shown row is laid out and text-measured on each render pass, and the list builds one row per step for the entire guide (some routes are 50 to 390 steps). A windowed or virtualized step list (building and measuring only the rows near the visible scroll range) would likely address both the recursion trigger and the per-frame layout cost.

Happy to provide sample files or test a patch. Environment: Retail 12.0.5 (12.0.5.67823), macOS 26.5, Apple M1 Max.