fix(debugger): removing a breakpoint while running no longer resurrects it on the next session - #23
Merged
ClarionLive merged 2 commits intoAug 21, 2026
Conversation
…rionLive#19, ClarionLive#21) BuildSymbols previously rejected nameRef == 0 as invalid, silently dropping _main's definition (its record legitimately points at pool offset 0) and leaving stack frames in _main mis-bound to the preceding module's last symbol, with a phantom SELF local appearing. Also adds a name-recovery heuristic for GROUP members whose nameRef is zeroed by the compiler despite a valid pool string existing (e.g. StringTheory.Value), recovering ~99.5% of confirmed cases by reading backward from a known-good neighbor. Adds temporary diagnostic CLI commands (scanrva, scanname, typemembers, typechain, poolback, scanmissingnames, surveymissingnames) used to investigate both issues, plus related locals/stack-walker/eval fixes and debugger.html/webview tweaks. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ts it on the next session _pending (the pad's own breakpoint staging list, resent wholesale to the engine on the next StartSession) and _svc.Breakpoints (the engine's confirmed, live list) are separate. Removing a breakpoint while a session is running only talked to the live engine, never trimming _pending — so a breakpoint removed mid-session silently came back the next time a session was started, since StartSession() re-sends the stale _pending entry. Now _pending is trimmed unconditionally, regardless of run state. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
geircodes
force-pushed
the
fix/breakpoint-removed-while-running-persists
branch
from
July 27, 2026 14:12
d4b5b83 to
46e7dd8
Compare
ClarionLive
pushed a commit
that referenced
this pull request
Aug 21, 2026
…#19, #21) Lands the commit shared by PRs #23, #24 and #25 on its own, so each of those three collapses to just its unique commit instead of carrying ~1100 duplicated lines. Fixes: - #19 phantom SELF local in main() — BuildSymbols' `nameRef < 1` guard dropped _main's definition record (which legitimately points at pool offset 0), leaving _main a symbol-less hole that stack frames mis-bound to the previous module's last method. Adds ResolveSymbolVerified, cross-checking a candidate against the +0x1C line table rather than the non-comparable +0x28 moduleIdx. - #21 (unnamed+N) GROUP members, e.g. StringTheory.Value — recovers the name by reading backward in the symbol pool from the group's smallest-mNameRef member, with duplicate / '@' / '$' rejection. ~99.5% of confirmed cases. Also carries temporary diagnostic CLI commands used in the investigation, related locals/stack-walker/eval fixes, and debugger.html/webview tweaks. Original author: Geir Stale Eidissen <ML-DEV-GSE@ml.no> Verified: ClarionDbg.Cli + ClarionDebugger.Addin build clean (0 warnings). Co-Authored-By: Claude Opus 5 (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
2 participants
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.
_pending(the pad's own breakpoint staging list, re-sent wholesale to the engine on the nextStartSession()) and_svc.Breakpoints(the engine's confirmed, live list) are two separate lists.OnGutterBpRemovedonly trimmed_pendingin the NOT-running branch — while a session is live, removing a breakpoint (via the editor gutter or the pane's X) only told the live engine, leaving the stale entry in_pending. Starting a new session later re-sends that stale_pendinglist, silently re-planting the breakpoint the user thought they'd deleted.Fix:
_pendingis now trimmed unconditionally, regardless of run state.Verified live: removed a breakpoint mid-session, started a fresh session — before the fix the "removed" breakpoint came back and was hit again; after, it stays gone.