go-delve/delve · error

can not continue execution of core process

Error message

can not continue execution of core process

What it means

ErrContinueCore (pkg/proc/core/core.go:190) is returned by Restart, ContinueOnce, and StepInstruction when a program is asked to run while being debugged from a core file. Core dumps are static snapshots: there is no live process to resume or step, so any execution request is rejected with this sentinel.

Source

Thrown at pkg/proc/core/core.go:190

	p      *process
	common proc.CommonThread
}

type osThread interface {
	Registers() (proc.Registers, error)
	ThreadID() int
}

var (
	// ErrWriteCore is returned when attempting to write to the core
	// process memory.
	ErrWriteCore = errors.New("can not write to core process")

	// ErrShortRead is returned on a short read.
	ErrShortRead = errors.New("short read")

	// ErrContinueCore is returned when trying to continue execution of a core process.
	ErrContinueCore = errors.New("can not continue execution of core process")

	// ErrChangeRegisterCore is returned when trying to change register values for core files.
	ErrChangeRegisterCore = errors.New("can not change register values of core process")
)

type openFn func(string, string) (*process, proc.Thread, error)

var openFns = []openFn{readLinuxOrPlatformIndependentCore, readAMD64Minidump}

// ErrUnrecognizedFormat is returned when the core file is not recognized as
// any of the supported formats.
var ErrUnrecognizedFormat = errors.New("unrecognized core format")

// OpenCore will open the core file and return a *proc.TargetGroup.
// If the DWARF information cannot be found in the binary, Delve will look
// for external debug files in the directories passed in.
func OpenCore(corePath, exePath string, debugInfoDirs []string) (*proc.TargetGroup, error) {
	var p *process

View on GitHub (pinned to a23773e6c3)

Solutions

  1. Do not issue continue/step/restart commands when the target is a core file; check target.Recorded()/backend type first.
  2. Limit core-file sessions to inspection commands (print, frame, stack, breakpoints skipped).
  3. If you need execution, reproduce with a live process: dlv debug/exec/attach instead of dlv core.
  4. For replay semantics, use delve's recorded-trace support (dlv replay) rather than expecting cores to run.

Example fix

// before
grp, _ := debugger.AttachFromCore(...) 
debugger.Continue() // -> can not continue execution of core process

// after
if recorded, _ := grp.Selected().Process().Recorded(); !isLiveCore(grp) {
    debugger.Continue()
} else {
    // inspect static state only: stack, variables, frames
}
Defensive patterns

Strategy: validation

Validate before calling

if isCoreTarget(tg) { return fmt.Errorf("cannot continue a core dump; inspect state only") }
// isCoreTarget checks the backend, e.g. via tg.Selected().Process().Recorded() and open path

Type guard

func isLiveProcess(tg *proc.TargetGroup) bool { t := tg.Selected(); return t != nil && !t.Process().Recorded() || t.Recorded() && t.Recorded() /* use backend info */ }

Try / catch

err := dbg.Continue()
if errors.Is(err, core.ErrContinueCore) {
    log.Println("core dump: execution control unsupported; use inspection commands")
    return nil
}

Prevention

When it happens

Trigger: Calling debugger.Continue(), Step/StepInstruction, or Restart against a target opened with OpenCore; also ClearCheckpoint-adjacent flows like Checkpoint() that funnel through ErrContinueCore.

Common situations: Automated tooling that reuses a live-debug workflow (continue until breakpoint) on a core dump; running 'dlv core' and typing continue/step at the prompt; test harnesses parameterized over live and core backends hitting the core case.

Related errors


AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31). Data as JSON: /api/errors/6099a98418a0aa20. Report an issue: GitHub.