diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 27 |
1 files changed, 27 insertions, 0 deletions
@@ -114,3 +114,30 @@ same thing, fetched separately and keyed differently — the split one on _cur ( cursor's function), the trace one on the decompiler's loaded function. That is how they ended up describing different functions. There is now one index, keyed to what the decompiler HOLDS, and both read it. + +## A stray navigation to the entry point during trace seeking + +Seen while building M3. After a trace seek, a SECOND _open_at arrives from a +worker callback and re-points the view at the entry function: + + ('_goto_ea', ['0x3160']) <- the seek's own navigation + ('_open_at', ['0x3160', 'main']) <- correct + ('_open_at', ['0x34d0', 'start']) <- stray, and it wins + +The cursor and _cur then sit on 'start' while the trace's pc is elsewhere, and it +does not settle — measured stable for 3+ seconds. Consequence: a cursor-based +action taken right after a seek (`>` seeks on the address under the cursor) acts +on the wrong address. + +Not _auto_land: 'start' is not in ENTRY_NAMES, and its guard was set. The +traceback only shows the Textual callback frame, so the origin is a +call_from_thread from some worker — most likely a navigation queued earlier +arriving late, which is the same shape as the stale-result bug fixed in 756589a +for _open_decomp_entry (that one got a sequence guard; the listing path did not). + +To reproduce: seek to an address executed twice, wait for the cursor to reach it, +then seek again and watch _cur. + +Workaround in place: nothing. The M3 tests place the cursor explicitly rather +than relying on where a seek left it, which is what a user does anyway (you point +at a line and ask about it) — but the drift is real and worth fixing. |