go-delve/delve · error

cannot write a breakpoint to a core file

Error message

cannot write a breakpoint to a core file

What it means

WriteBreakpoint on the core-file process (pkg/proc/core/core.go:247) unconditionally returns the error 'cannot write a breakpoint to a core file'. Core dumps are static memory images, so INT3-style patching of code bytes is impossible. It exists so the process satisfies the proc.ProcessInternal interface.

Source

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

	})
	_, err = addTarget(p, p.pid, currentThread, exePath, proc.StopAttached, "")
	return grp, err
}

// BinInfo will return the binary info.
func (p *process) BinInfo() *proc.BinaryInfo {
	return p.bi
}

// EntryPoint will return the entry point address for this core file.
func (p *process) EntryPoint() (uint64, error) {
	return p.entryPoint, nil
}

// WriteBreakpoint is a noop function since you
// cannot write breakpoints into core files.
func (p *process) WriteBreakpoint(*proc.Breakpoint) error {
	return errors.New("cannot write a breakpoint to a core file")
}

// Recorded returns whether this is a live or recorded process. Always returns true for core files.
func (p *process) Recorded() (bool, string) { return true, "" }

// Restart will only return an error for core files, as they are not executing.
func (p *process) Restart(*proc.ContinueOnceContext, string) (proc.Thread, error) {
	return nil, ErrContinueCore
}

// ChangeDirection will only return an error as you cannot continue a core process.
func (p *process) ChangeDirection(proc.Direction) error { return ErrContinueCore }

// GetDirection will always return forward.
func (p *process) GetDirection() proc.Direction { return proc.Forward }

// When does not apply to core files, it is to support the Mozilla 'rr' backend.
func (p *process) When() (string, error) { return "", nil }

View on GitHub (pinned to a23773e6c3)

Solutions

1. Do not set breakpoints on core dumps; inspect the captured state directly (stack, goroutines, variables).
2. Use the core's snapshot location: the crash state is already 'stopped at' the faulting point.
3. To use breakpoints, run the program live (dlv debug/exec/attach) with the same inputs.
4. If you need conditional post-mortem inspection, use recorded replay (dlv replay) which supports stepping forward.

Example fix

// before
_, err := dbg.SetBreakpoint(bp) // -> cannot write a breakpoint to a core file

// after
if coreSession {
    // inspect existing state instead of setting breakpoints
    frames, _ := dbg.Stacktrace(goroutineID, 20)
} else {
    dbg.SetBreakpoint(bp)
}

if isCoreTarget(tg) { return errors.New("breakpoints unsupported on core dumps") }

func canSetBreakpoints(tg *proc.TargetGroup) bool { return !isCoreTarget(tg) }

err := dbg.SetBreakpoint(bp)
if err != nil && strings.Contains(err.Error(), "cannot write a breakpoint to a core file") {
    log.Println("core dump: inspect the already-stopped crash state instead")
}

When it happens

Trigger: Calling WriteBreakpoint on a target from OpenCore, directly or through debugger.SetBreakpoint when attaching to a core with 'dlv core'.

Common situations: Trying to set a breakpoint at a crash site in a core session; automation that always sets breakpoints before analysis; IDE sessions pointed at a core dump where continue/breakpoints are meaningless.

Related errors

• short read
• can not continue execution of core process
• can not change register values of core process
• unrecognized core format
• checkpoint not found

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