Label native crashes by type instead of always 'Stack overflow!'#78
Merged
Conversation
seTranslator (bbruntime_dll.cpp), the Windows structured-exception translator, had a switch with no `break` statements, so every CPU fault fell through to the last case: a divide-by-zero, a null/dangling object access violation, and an illegal instruction were ALL reported to the user as "Stack overflow!". The mislabel sends anyone debugging (most commonly) a Null-object access down a stack-overflow rabbit hole. Contradicts INTENT #6 ("trust the runtime … instrumented enough to diagnose"). Add `break;` after each case so each exception code maps to its own message. Minimal correctness fix -- no new codes, no pipeline change. Windows-only by nature (_set_se_translator); macOS has its own signal path. Verified: a runtime integer divide-by-zero now reports "Integer divide by zero" (was "Stack overflow!"). In -t mode the panic message reaches stdout via the DummyDebugger, so it is capturable; scripts/fixtures/divzero.bb is the deliberate crash fixture used by the test harness (it panics + exits non-zero by design, so it lives outside tests/ and the corpus sweep). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
test.bat asserts a runtime divide-by-zero is labeled "Integer divide by zero" (not "Stack overflow!") via :expect_failure against scripts/fixtures/divzero.bb. test.sh adds the parity check, guarded so it only flags the regression where the structured-exception message actually appears (no-op on the compile-only macOS path). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Root cause (switch fall-through), the -t stdout verification path, and deferred follow-ups (the GC doc false-citation from #67; contextual-keyword Phase 2). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Non-technical summary
When a compiled Blitz program hits a CPU-level fault — a divide-by-zero, a Null/dangling object access, an illegal instruction, or a real stack overflow — BlitzForge is supposed to tell you which one. A switch-statement bug meant every such crash was reported as "Stack overflow!", including the most common one (touching a Null object). That actively misdirects debugging. This PR makes each fault report its true cause. Advances INTENT #6 ("trust the runtime… instrumented enough to diagnose").
Technical summary
seTranslatorinsrc/blitzrc/bbruntime_dll/bbruntime_dll.cpp(the Windows_set_se_translatorhandler) had aswitchover exception codes with nobreakstatements — sopanicStralways fell through to the final case, "Stack overflow!". Addedbreak;after each case. Minimal correctness fix; no new codes, no change to the panic/bbEx/block-trace pipeline. Windows-only by nature; macOS has its own signal path (out of scope).Verified: a runtime integer divide-by-zero now reports
Error: Integer divide by zero(wasError: Stack overflow!). In-ttest mode the panic message reaches stdout via theDummyDebugger, so it's capturable.Acceptance criteria + results
test.bat(:expect_failure … "Integer divide by zero") +test.shparity, run againstscripts/fixtures/divzero.bb— a deliberate crash fixture placed outsidetests/(it panics +exit(1)by design, so it must not run in the-tsuite loop) and outside the corpus-sweep dirs.test.batgreen; build 0 errors; corpus sweep unaffected.Trade-offs, deferred follow-ups
FLT_DIVIDE_BY_ZERO,PRIV_INSTRUCTION) — scope creep beyond the missing-break bug.Testblock can't assert this (the panicexit(1)s mid-run), hence the standalone-fixture CLI contract.help/language/lang_ref_modern.htmlcitestests/GarbageCollectionTest.bbas evidence for the "reference cycles leak — break them yourself" contract, but that test has no cycle case. A recon pitch this iteration proposed a GC acceptance suite that would both pin the contract and make the citation true; worth doing soon.Release+ expression-position keywords).🤖 Generated with Claude Code