Running all tests with `cargo test --test '*'` causes cross-contamination:
OnceLock-based test binaries (comment_tests etc.) leave the bridge running,
and daemon_tests reuses then stops that bridge, leaving subsequent daemon
tests unable to start a fresh bridge ("Could not find project").
Split into separate cargo test invocations matching test.yml groups, with
explicit bridge stops between groups to ensure clean state.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Fix rustfmt issue in tests/common/mod.rs (single-line .context() chain)
- Remove stale drop(harness) calls that now drop &'static references
- Use _harness for unused bindings that only ensure bridge initialization
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
On macOS, Ghidra stores project data in mmap pages that aren't flushed
to disk while the bridge runs. Per-test DaemonTestHarness stop/restart
cycles cause data loss. Use OnceLock<DaemonTestHarness> to share a
single bridge per test binary, matching the readonly_tests pattern.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Root cause: on macOS, `ghidra stop` triggers Ghidra's project close
which truncates .gpr to 0 bytes and leaves .rep with only metadata
stubs (~index.dat, project.prp) but no actual program data. This
causes all subsequent bridge starts to fail with "program file(s)
not found".
Changes:
- Remove `ghidra stop` from CI setup (corrupts macOS projects)
- Remove Step 3 bridge stop from ensure_test_project (same issue)
- Validate .gpr is non-empty AND idata/ has program data beyond
just ~index.dat stubs
- Clean up stale project files before re-import
- Bump cache keys v3→v4 to invalidate broken caches
- Remove diagnostic output from test.yml
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Lists all files in the projects directory after import+analyze+stop
to debug why macOS cache is only 919 bytes while Ubuntu saves 5.6MB.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The ghidra-setup job left the bridge running after import+analyze,
so the Ghidra JVM hadn't flushed the project database to the .rep
directory when the post-job cache save ran. This resulted in caches
containing only the ~1KB .gpr file without any analysis data.
- Stop bridge after import+analyze in ghidra-setup (both workflows)
- Bump cache keys v2→v3 to invalidate broken empty caches
- Validate .rep has actual files, not just an empty directory
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Introduced `decompile_project` function in IlSpyBridge to handle project-style decompilation, generating per-type .cs files.
- Updated FFI layer to support new decompile_project functionality.
- Enhanced CLI to accept output directory for project decompilation, ensuring compatibility with existing type and method flags.
- Improved error handling and output formatting for decompilation results.
- Added comprehensive command reference for ilspy-cli, detailing usage for detecting .NET vs native binaries, listing types and methods, and searching decompiled source.
- Integrated memory reading capabilities in GhidraCliBridge for enhanced analysis workflows.
- Updated main.rs to robustly check for existing bridge instances, improving reliability in project mode.
Alexander Kiselev