Repository navigation
Rethink debug lifecycle #1210
Description
Currently, the initial breakpoint set up when creating a sandbox is set on the entrypoint function, which means that, when creating a sandbox from an initialised snapshot, it is never set up or executed, and a debugger has no easy way to attach.
Relatedly, the debugging infrastructure (and the initial breakpoint) is/are set up in Sandbox::new(), which means that whether a sandbox has a debug thread or not is decided once, at sandbox creation time, but there is also only one place to attach a debugger (at sandbox initialisation time): future function calls, or restored sandboxes, might not be easy to debug, even though they have a debug thread consuming resources.
See also: this comment
Activity
ludfjig commentedon Feb 4, 2026
Note that #1120 might further change debugging due to resetting debug register on snapshot-restores, which could potentially discard breakpoints etc. One possible solution might be to not reset debug registers if
gdbcargo feature is enabled?dblnz commentedon Feb 25, 2026
This is a note to think about the future of debugging a sandbox.
Currently, we rely on the
entrypointfunction breakpoint to allow the user the time to add new breakpoints, but if a sandbox has been snapshotted after the initialise phase, that won't work.simongdavies commentedon Feb 25, 2026
Additionally we may want to consider that restore/resetting a sandbox might work very differently as we move towards using Snapshots as the basis for creating Sandboxes