go-delve/delve · error

not implemented

Error message

not implemented

What it means

The core-file backend (pkg/proc/core) implements Process for offline analysis of core dumps. SetUProbe, which registers a non-stop eBPF uprobes tracepoint on a function, cannot work on a static core dump — there is no live process to attach a uprobe to. The stub therefore panics to make it obvious this operation is unsupported for core files.

Source

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

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

// Checkpoint for core files returns an error, there is no execution of a core file.
func (p *process) Checkpoint(string) (int, error) { return -1, ErrContinueCore }

// Checkpoints returns nil on core files, you cannot set checkpoints when debugging core files.
func (p *process) Checkpoints() ([]proc.Checkpoint, error) { return nil, nil }

// ClearCheckpoint clears a checkpoint, but will only return an error for core files.
func (p *process) ClearCheckpoint(int) error { return errors.New("checkpoint not found") }

func (p *process) SupportsBPF() bool {
	return false
}

func (p *process) SetUProbe(fnName string, goidOffset int64, args []ebpf.UProbeArgMap) error {
	panic("not implemented")
}

// StartCallInjection notifies the backend that we are about to inject a function call.
func (p *process) StartCallInjection() (func(), error) { return func() {}, nil }

func (p *process) EnableURetProbes() error {
	panic("not implemented")
}

func (p *process) DisableURetProbes() error {
	panic("not implemented")
}

// ReadMemory will return memory from the core file at the specified location and put the
// read memory into `data`, returning the length read, and returning an error if
// the length read is shorter than the length of the `data` buffer.
func (p *process) ReadMemory(data []byte, addr uint64) (n int, err error) {
	n, err = p.mem.ReadMemory(data, addr)

View on GitHub (pinned to a23773e6c3)

Solutions

1. Only use eBPF/tracepoint tracing with live backends (native); use breakpoints on the core session for offline inspection
2. Guard code paths: check the backend kind before calling SetUProbe
3. Replace the panic in the stub with a returned error if you fork Delve and want graceful degradation

Example fix

// before
func (p *process) SetUProbe(fnName string, goidOffset int64, args []ebpf.UProbeArgMap) error {
	panic("not implemented")
}
// after
func (p *process) SetUProbe(fnName string, goidOffset int64, args []ebpf.UProbeArgMap) error {
	return errors.New("SetUProbe not supported for core files")
}

if isCoreSession(proc) {
	return errors.New("SetUProbe not supported for core files")
}

When it happens

Trigger: Calling SetUProbe on a Process obtained from a core dump, e.g. via debugger features that use eBPF tracing (trace subcommand with --ebpf, follow-exec tracing) while attached to a core file instead of a live process.

Common situations: Running 'dlv core dumpfile binary' and attempting tracepoint/eBPF-based tracing; a client (IDE plugin, CLI) issuing SetUProbe-like requests against a core session; tests that mix core-file and ebpf backends.

Related errors

• Unhandled case: existing entry is %v len %v, new is %v len %
• not implemented
• short read
• can not continue execution of core process
• can not change register values of core process

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