Update the README for the sanitizer work - #85
Merged
Merged
Conversation
The "Finding bugs in guest programs" section had gone stale in three
ways, two of them wrong rather than merely incomplete:
- It quoted the old report format ("1 distinct violation(s)"), which
became per-PC grouping in #79.
- It claimed real PhxAss "runs clean" under --sanitize. It no longer
does: #84 poisoned the allocators PhxAss actually uses, and it turns
out to read two bytes past its own 40-byte timerequest. That is a
genuine find rather than a regression, so the README now says so
instead of claiming silence.
- It predated --sanitize-uninit (#79), --dirty-heap (#81) and source
locations (#74), so it undersold the feature by three increments.
The lead example is now a real m68k-amigaos-gcc stack smash with its
0x41414141 and symbol attribution, since that is both the most
recognisable bug shape and the case the whole effort started from (gcc
having no -fsanitize=address).
Also records the two things it genuinely cannot see -- intra-frame stack
overflows, and malloc inside a C runtime's own pool, which
sub-allocates via exec.library/Allocate rather than the allocators
volamos guards (#83) -- because overselling a bug detector is how people
stop trusting it.
The Status section said the three-oracle parity harness "hasn't formally
started yet". tools/compare_three_way.py exists and works: it runs the
same binary under volamos, vamos and a real Kickstart via Copperline.
Updated, including that it is local-only (real ROM and Workbench media,
neither committable) and needs a --model matching its --rom, and
pointing at the hardware-verified vamos differences page. Also added
pLhA and SAS/C 6.58 to the real-binary list they were missing from.
Every command and output block here was run and copied verbatim, and
the two load-bearing claims were re-verified: PhxAss reports exactly one
violation, and sc's output object file is still byte-identical with and
without --sanitize.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AKBJRT9j5APTyKyZtj8f23
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The README's sanitizer section had gone stale — and two of the three ways were wrong, not merely incomplete.
What was wrong
--sanitize. It doesn't any more: Poison the other allocators that carve from the guest heap #84 poisoned the allocators PhxAss actually uses, and it reads two bytes past its own 40-bytetimerequest. That's a genuine find, so the README says so rather than claiming silence.1 distinct violation(s)), which became per-PC grouping in Add --sanitize-uninit and --sanitize-ignore-pc (issue #68) #79.--sanitize-uninit(Add --sanitize-uninit and --sanitize-ignore-pc (issue #68) #79),--dirty-heap(Add --dirty-heap: poison-fill non-MEMF_CLEAR allocations (issue #80) #81) and source locations (Use HUNK_DEBUG LINE information to report source file:line instead of raw addresses #74), so it undersold the feature by three increments.What it says now
The lead example is a real
m68k-amigaos-gccstack smash, with itsfound 0x41414141and(at ___main+0x3c)symbol attribution — both the most recognisable bug shape and the case this whole effort started from, since gcc has no-fsanitize=address.It also records the two things the sanitizer genuinely cannot see: intra-frame stack overflows (compiler instrumentation territory, invisible to valgrind too), and
mallocinside a C runtime's own pool, which sub-allocates viaexec.library/Allocaterather than the allocators volamos guards (#83). Overselling a bug detector is how people stop trusting it.Status section
It said the three-oracle parity harness "hasn't formally started yet".
tools/compare_three_way.pyexists and works — same binary under volamos,vamosand a real Kickstart via Copperline. Now documented, including that it's local-only (real ROM and Workbench media, neither committable) and needs a--modelmatching its--rom, with a pointer to the hardware-verified Differences from vamos page. Added pLhA and SAS/C 6.58 to the real-binary list they were missing from.Verification
Every command and output block was run and copied verbatim, and the two load-bearing claims re-checked: PhxAss reports exactly one violation, and
sc's output object file is still byte-identical with and without--sanitize.🤖 Generated with Claude Code
https://claude.ai/code/session_01AKBJRT9j5APTyKyZtj8f23