* fix(kuna): name the setting that owns a timed-out Kuna run
A Kuna run past its deadline surfaced the generic "Analysis took too
long. Try a smaller request" message. The request is already one
function or one whole-program scan, and the same run takes as long
again, so the advice was wrong and REA_KUNA_TIMEOUT_MS or
REA_KUNA_PROJECT_TIMEOUT_MS was never mentioned.
Each Kuna command now carries a KunaDeadline: the configured
milliseconds and the setting that owns them, from KunaConfiguration.
A timeout reports, for example, "kuna decompile did not finish within
REA_KUNA_TIMEOUT_MS (120000 ms)." Its remediation says to raise that
setting and restart REA, and for a single-function decompile that the
session's project export can still answer. AnalysisTimeoutError now
accepts a producer message and remediation, which projection uses and
per-waiter scan errors keep.
Refs #1957
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* docs(kuna): scope the provider_timeout statement to direct Kuna runs
A timed-out project export is reported through the export failure as
capability_unavailable, not provider_timeout.
Refs #1957
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(kuna): verify native xrefs under the project deadline
The provider's xrefs scan runs under REA_KUNA_PROJECT_TIMEOUT_MS, but the
native oracle in verify:kuna aborted at REA_KUNA_TIMEOUT_MS. A scan that
fit the project deadline but not the function deadline failed
verification although the provider answered it. Use the same deadline.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* fix(kuna): answer a repeated single-function request without re-running Kuna
A session dropped each single-function run once it settled, so a repeat
request for the same procedure re-ran `kuna decompile --addr`, which
analyzes the whole image again. After a failed export every pseudocode
request uses that path for the rest of the session.
Keep each completed text by entry address, within a 16 MiB least recently
used budget, until the export's reader is adopted or the session closes.
Failed and cancelled runs are not kept. The export's text still supersedes
a kept one.
Refs #1957
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* test(kuna): pin that a kept text's hit refreshes its recency
With two 9 MiB texts only one fit the budget, so a repeated lookup could
not change which entry was dropped. Use three 6 MiB texts: re-reading main
leaves parse least recently used, so keeping broken must drop parse.
Refs #1957
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
A single-function run whose process tree could not be proven stopped
released its run slot immediately, so the next queued run started while
the old tree might still run, and repeated unproven stops bypassed the
bound. The retained run now carries its slot, and close releases it only
after a retried stop is proven.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
While the project export builds, every pseudocode request started its own
`kuna decompile --addr` process, and each one analyzes the whole image
again. A cold batch_decompile therefore launched one process per address,
including duplicates, with no bound.
Requests for one entry now share one run, which stops when its last waiter
is cancelled; that waiter still receives the run's outcome, including
unproven cleanup. A provider-wide pool admits at most the host's cores
beyond REA_KUNA_JOBS (at least one) at once, and a queued request is
answered from the export when it finishes first.
Refs #1957
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
