From d1deca0826a9e04da195ba3eeb344cd18d38ea17 Mon Sep 17 00:00:00 2001
From: blasty <blasty@local>
Date: Tue, 28 Jul 2026 15:16:34 +0200
Subject: trace: stop the decompiler thrashing during a step (and correct the
 record)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

I blamed decomp_map in the last commit. It was innocent: called directly it
returns 769 lines, 475 with addresses, for exactly the function I said it
returned four for. The four-line map belonged to a PLT stub the decompiler had
momentarily switched to, and I sampled mid-bounce.

The actual fault: _seek_split decided "has execution left the decompiled
function?" from _split_range, which is maintained by a guarded async path
(_apply_split_map drops its result if _cur moved while in flight) and therefore
lags during stepping. A stale range made every step look like a function change,
so the decompiler bounced main -> stub -> main, each bounce paying a synchronous
769-line map fetch on the UI thread.

Now the decision comes from the map the trail painting already holds, keyed to
what the decompiler currently HAS loaded. The bouncing is gone — three map
fetches across twelve steps instead of one per step — and the pseudocode cursor
follows every instruction the decompiler attributes to a line, including across
a call into another function.

What it does NOT do: guess. Roughly half of a function's instructions have no
line attributed, and the obvious fallback (nearest mapped address at or before
the pc) is unsound — C lines are not monotonic in address, and it put an
instruction early in main on line 708, "sub_2040();", near the end. The cursor
waits instead; the trail still marks where you are.

tests: +1 trace UI (26) — over ~28 steps, every instruction that IS mapped is
followed by the pseudocode cursor. 212/0 scenarios.

TODO corrected: the entry blaming decomp_map now says what actually happened,
including that _split_ea2line/_split_range are still fed by the laggy path and
remain a latent issue for the split view's own sync.
---
 tests/test_trace_ui.py | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

(limited to 'tests')

diff --git a/tests/test_trace_ui.py b/tests/test_trace_ui.py
index 7ffe20f..5d620a9 100644
--- a/tests/test_trace_ui.py
+++ b/tests/test_trace_ui.py
@@ -231,6 +231,27 @@ async def run() -> int:
                       lst.trail.get(t.ip(app._t)) == "now",
                       f"{lst.trail.get(t.ip(app._t))}")
 
+                # The pseudocode cursor follows too — but only for instructions
+                # the decompiler actually attributes to a line. About half
+                # aren't, and the tempting fallback (nearest mapped address at
+                # or before the pc) is unsound because C lines are not monotonic
+                # in address: an early instruction resolved to a line near the
+                # END of the function. Better to wait than to jump somewhere
+                # unrelated.
+                dec = app.query_one(DecompView)
+                mapped = missed = 0
+                for k in range(2, 30):
+                    app._seek(base + k)
+                    await pilot.pause(0.3)
+                    pc = t.ip(app._t)
+                    if app._trail_map_ea == dec.loaded_ea and pc in app._trail_line_of:
+                        mapped += 1
+                        if dec.cursor != app._trail_line_of[pc]:
+                            missed += 1
+                check("the pseudocode cursor follows every mapped instruction",
+                      mapped > 3 and missed == 0,
+                      f"{mapped} mapped, {missed} not followed")
+
     print(f"\n{PASS} passed, {FAIL} failed")
     return 1 if FAIL else 0
 
-- 
cgit v1.3.1-sl0p