fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: the timer message's consumer is a runtime registry, not a tag compare

Browse Source 
The move I flagged last iteration -- "0xAB03E5BA is built once, so
nothing consumes it" -- is refuted by its own control: 25 of the 40
distinct 0xAB03xxxx tags in the image are built exactly once (62.5 %),
and no 4-aligned word anywhere in the image begins 0xAB03, so tags are
never stored statically.

What does stand:
  * sub_82175C20(bus+4, &msg) is a ring-buffer PUSH, not a dispatch.
  * The message class has a one-method vtable {scalar deleting dtor}
    with an MSVC RTTI locator at vtable[-1] -- no handler of its own.
  * The bus at [0x828F35DC] has a map at +8216, looked up via
    sub_82254A08 from sub_823001E8, whose only caller is the per-frame
    pump sub_8230C398.

So the item is NOT settled: the insert path into bus+8216 is unread,
and whether running out of time ends the mission is still unknown.

Docs only; ISL artefacts regenerate byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-27 09:12:36 +00:00
parent d79f59d24e
commit bf17f19f67
2 changed files with 72 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
docs/re/BACKLOG.md
View File

@@ -336,6 +336,34 @@ unknown, what evidence exists, and what the first step would be. Move an item in
unread, as is what B reaching zero does, and whether all 170 `timer_stop` sites
are phase teardown.
* 🔎🔴 **(2026-08-27) THE TIMER MESSAGE'S CONSUMER: LOCATED, NOT READ — and the
argument I was about to make is REFUTED BY ITS OWN CONTROL.
[structures/isl-mission-timer](structures/isl-mission-timer.md).**
The tempting move was "`0xAB03E5BA` is built at exactly one site, so nothing
consumes the timer message". **The control kills it: 25 of the 40 distinct
`0xAB03xxxx` tags in the image are built exactly once (62.5 %)** — single-site
construction is the *majority*, not an anomaly. And the tag appears **nowhere
in the image as a 4-byte word** — in fact **no 4-aligned word anywhere begins
`0xAB03`** — so there is no static table of subscribed tags to find either.
✅ **Two structural reads that do stand.** (1) The post is a **queue push, not a
dispatch**: `sub_82175C20(bus+4, &msg)` is a ring-buffer append (capacity `+8`,
head `+12`, count `+16`, array `+4`, grown via `sub_8228E208`) and never looks
at the message. (2) The message class has a **one-method vtable**:
`0x820A8D18`–`0x820A8DA0` is a run of 2-word records
`{ sub_82301C20, 0x8210Exxx }`; the timer message's vptr `0x820A8D68` gives
`vtable[0] = sub_82301C20` (a scalar deleting destructor — stores `0x820A7014`
over the vptr, conditionally frees) and `vtable[-1] = 0x8210E288`, an **MSVC
RTTI locator** (`0,0,0, &typeDesc 0x8289D094, &classHierarchy 0x8210E29C`,
`numBaseClasses = 3`) — data, not code, and below `sylpheed.db`'s `0x82150000`
floor. **So the message carries no handler of its own**, and dispatch is neither
a literal compare nor virtual on the message.
🟡 **Located:** the bus at `[0x828F35DC]` carries a **map at `+8216`**, looked
up through `sub_82254A08` from **`sub_823001E8`**, whose only caller is
`sub_8230C398` — the per-frame message pump, called from the frame loop
(`0x821A6544`) with the frame `dt`. So the question reduces to **what inserts
into `bus+8216` and with which key**. That path is unread, so **the item is NOT
settled**: whether running out of time ends the mission is still unknown.
## ✅✅ SOLVED — the mission freeze was a modal sign-in dialog (2026-08-26)
`XamShowSigninUI` opens a modal dialog and `xeXamDispatchDialog` blocks the