Skip to content

Stop QEMU read_mem32/write_mem32 from leaving the target permanently halted#57

Merged
harshverma27 merged 1 commit into
mainfrom
claude/issue-47-fix
Jun 30, 2026
Merged

Stop QEMU read_mem32/write_mem32 from leaving the target permanently halted#57
harshverma27 merged 1 commit into
mainfrom
claude/issue-47-fix

Conversation

@harshverma27

Copy link
Copy Markdown
Owner

Summary

  • Fixes read_mem32/write_mem32: transient continue_execution failure leaves QEMU target permanently halted #47
  • read_mem32/write_mem32 halt the target with interrupt(), perform the read/write, then resume with continue_execution().await?. If resume failed, the ? propagated immediately, discarding an already-successful read/write result and leaving the target halted — every subsequent interrupt() call for the rest of the run then hit an already-halted target.
  • Resume is now attempted with one retry (resume_with_retry), covering a transient GDB-RSP blip (e.g. a TCP hiccup) that self-heals on a second attempt.
  • The resume outcome is tracked separately from the read/write outcome: a resume failure is recorded via record_failure (so finish() correctly reports Failed instead of silently leaving the target halted with no indication anything went wrong) without discarding an already-successful read or write result.
  • Same fix applied symmetrically to both read_mem32 and write_mem32.

Test plan

  • cargo test -p nucleus-hil --lib — 62 passed, including new regression tests:
    • resume_with_retry_recovers_after_one_transient_failure
    • resume_with_retry_fails_after_two_consecutive_failures
    • read_mem32_preserves_a_successful_read_even_when_resume_never_succeeds
    • write_mem32_records_failure_when_resume_never_succeeds
  • cargo clippy -p nucleus-hil -p nucleus-cli --all-targets -- -D warnings — clean.
  • cargo fmt --all -- --check — clean.

Generated by Claude Code

…halted

stub.continue_execution().await? propagated via ? after a successful
read/write, discarding the valid result and leaving the target halted for
the rest of the run -- every subsequent interrupt() then hit an
already-halted target. Resume now retries once (covers a transient GDB-RSP
blip) and its outcome is tracked separately from the read/write result, so
a resume failure is recorded (finish() reports Failed) without discarding
an already-successful read or write.
@harshverma27
harshverma27 merged commit 0a4ad79 into main Jun 30, 2026
@harshverma27
harshverma27 deleted the claude/issue-47-fix branch June 30, 2026 12:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

read_mem32/write_mem32: transient continue_execution failure leaves QEMU target permanently halted

2 participants