vcores: hos_vcore_back leaves the escape flag up (not reachable today; review point from #2302) #2386

Closed

opened 2026-11-11 16:49:30 +00:00 by mooki000 · 0 comments

mooki000 commented

2026-11-11 16:49:30 +00:00

(Migrated from github.com)

Hookshot version

main b744b1ec, from source

What kind of problem

Something else

What happened

Not a fault a player can hit today: a hardening that @hckrman101 named as an optional point when he reviewed #2302 (comment).

Since #2302 an escaped thread (one that ran without a virtual core, vc_escaped set) takes a core again after its next block: its next hos_vcore_away() answers 1 and clears the flag. hos_vcore_back() itself leaves the flag alone. Every back in the code today follows an away that answered 1, except the two at a thread's start, where no escape can be up yet. So the flag is always down while a core is held.

A later change that calls back without its away on an escaped thread would take a core and leave the flag up. The thread's next outer block would give the core up as usual, and a block nested inside it would then answer 1 and take a core in the middle of the outer block.

Expected: after any hos_vcore_back() the flag is up only when the thread is again running without a core.

Where in the game

Not reachable in the game today (no call reaches the case)

How often

Never today

Graphics card and driver version

Does not depend on it

CPU, RAM and operating system

i9-13900K, 96 GB, Arch Linux

Changes from the defaults

None

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

Not a game run. tests/test_vcore_escape.py with the two new cases of the pull request shows it against main's host/hos_thread.c.

Claim

I'm working on this: the pull request with the change and its test follows this issue directly. By docs/workflow.md: S4 (no player-visible fault; guards a merged fix against a future change) x confidence 1.0 (the test fails on main's source and passes with the change, g++ and clang++).

### Hookshot version main b744b1ec, from source ### What kind of problem Something else ### What happened Not a fault a player can hit today: a hardening that @hckrman101 named as an optional point when he reviewed #2302 ([comment](https://git.magicbean.dev/MagicBeanDev/Hookshot/pulls/2302)). Since #2302 an escaped thread (one that ran without a virtual core, `vc_escaped` set) takes a core again after its next block: its next `hos_vcore_away()` answers 1 and clears the flag. `hos_vcore_back()` itself leaves the flag alone. Every `back` in the code today follows an `away` that answered 1, except the two at a thread's start, where no escape can be up yet. So the flag is always down while a core is held. A later change that calls `back` without its `away` on an escaped thread would take a core and leave the flag up. The thread's next outer block would give the core up as usual, and a block nested inside it would then answer 1 and take a core in the middle of the outer block. Expected: after any `hos_vcore_back()` the flag is up only when the thread is again running without a core. ### Where in the game Not reachable in the game today (no call reaches the case) ### How often Never today ### Graphics card and driver version Does not depend on it ### CPU, RAM and operating system i9-13900K, 96 GB, Arch Linux ### Changes from the defaults None ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt Not a game run. `tests/test_vcore_escape.py` with the two new cases of the pull request shows it against main's `host/hos_thread.c`. ### Claim I'm working on this: the pull request with the change and its test follows this issue directly. By `docs/workflow.md`: S4 (no player-visible fault; guards a merged fix against a future change) x confidence 1.0 (the test fails on main's source and passes with the change, g++ and clang++).