fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

fix(decoder): mount the disassembly database, which it had lost

Browse Source 
`SYLPHEED_DB=/xenia-rs/sylpheed.db` named a path that no longer exists. The
xenia-rs repo was retired by the consolidation, its local clone was deleted, and
the `/xenia-rs` mount that served the database was removed in #61 because it
pointed at nothing. The env var stayed. So the decoder had NO database: `zq.py`
and `/sylph-dis` -- most of what a static-RE brief asks for -- could not run.

Mounted read-only at the container's repo root instead, which is where `zq.py`
looks when `$SYLPHEED_DB` is unset, so there is no variable left to drift out of
step with the mount. That drift is the whole bug: a path in an env var and a
path in a mount, maintained separately.

Read-only is deliberate. The host owns the file, DuckDB takes an exclusive lock
to write, and two agents plus the human sharing one database would corrupt it.
Regenerating means writing elsewhere and pointing $SYLPHEED_DB at it.

Missing-file cases now say so and print the command that builds one, rather than
starting an agent that discovers it mid-iteration.

Verified in the real agent image: DB mounted, no env var set,
`zq.py fn 0x824609C8` -> `Pak_FindEntryByName`, `zq.py classes` lists RTTI.

The brief's tooling table also claimed the old path, and said nothing about the
oracle binary; both corrected. It now records that the built Canary carries
RE-INPUT/RE-DRAW but NOT the audit_61 branch probe -- measured with `strings`
on both built binaries, zero hits; it is on two other branches (fork issue #1).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude
2026-09-20 17:14:06 +02:00
parent b9d009b7a2
commit 8108958a77
2 changed files with 37 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/agents/decoder-loop.md
View File

@@ -56,11 +56,23 @@ rather than left in a document you might not reach.
| path | what | env |
|---|---|---|
| `/image/sylpheed.pe` | the decompressed executable image | `SYLPHEED_PE` |
| `/xenia-rs/sylpheed.db` | a disassembly database, 586 MB | `SYLPHEED_DB` |
| `sylpheed.db` at the repo root | the disassembly database, 337 MB | — (`zq.py` finds it; `$SYLPHEED_DB` only to override) |
| `/canary/build/bin/Linux/Release/xenia_canary` | the built oracle, inside the `/canary` mount | — |
| `/disc` | the extracted disc | `SYLPHEED_DISC` |
| `/iso/game.iso` | the retail ISO Canary boots | `SYLPH_ISO` |
| `/canary` | the Canary source, read-write | `XENIA_SRC` |
⚠️ **The database is read-only and is NOT in git** — it is a build artefact, and
`docs/re/captures/` is the same (issue #49). If either is missing the launcher
says so and prints the command that builds it. Query the database with
`python3 tools/zq.py …`, never by reading a disassembly dump.
⚠️ **The built Canary carries the `RE-INPUT`/`RE-DRAW` instrumentation but NOT
the `audit_61` guest-PC branch probe** — that lives only on
`auto/canary-instrumentation-snapshot-2026-07-28` and `phase-a-tracing`
(fork issue #1), so a probe run needs those two commits on `sylpheed-re` and a
rebuild first. Verified by `strings` on the binary, not assumed.
**The `.pe` is a flat VA dump**: file offset = `VA - 0x82000000`. Reading
`0x820A1630` is `seek(0xA1630)`. No XEX decrypt, no LZX, **no booted emulator** —
dumping guest memory works but makes the whole static corpus depend on a running