go-delve/delve · error

error creating tracepoint in function %s

Error message

error creating tracepoint in function %s

What it means

After resolving the destination function, Delve installs eBPF uprobes/tracepoints on it via createFunctionTracepoints. This error is returned when that call fails, wrapped only with the function name — the underlying cause (e.g. probe limit, permission problem, unsupported symbol) is discarded because fmt.Errorf does not wrap err. It indicates the kernel/ebpf layer refused the tracepoint for the resolved function.

Source

Thrown at service/debugger/debugger.go:1517

					disasm, err := proc.Disassemble(t.Memory(), regs, t.Breakpoints(), tgt.BinInfo(), pc, pc+maxInstLen)
					if err != nil {
						return false, fmt.Errorf("failed to disassemble instruction: %w", err)
					}

					// Extract address from the decoded instruction's destination location
					var addr uint64
					if len(disasm) > 0 && disasm[0].DestLoc != nil {
						addr = disasm[0].DestLoc.PC
					} else {
						return false, fmt.Errorf("failed to extract call destination from instruction at PC %#x", pc)
					}
					fn := tgt.BinInfo().PCToFunc(addr)
					if fn == nil {
						return false, fmt.Errorf("PCToFunc returned nil")
					}
					err = createFunctionTracepoints(d, fn.Name, rootstr, followCalls)
					if err != nil {
						return false, fmt.Errorf("error creating tracepoint in function %s", fn.Name)
					}
					dynchildren, err := d.traverse(t, fn, sdepth+1, followCalls, rootstr)
					if err != nil {
						return false, fmt.Errorf("error calling traverse on dynamic children")
					}
					for _, child := range dynchildren {
						err := createFunctionTracepoints(d, child, rootstr, followCalls)
						if err != nil {
							return false, fmt.Errorf("error creating tracepoint in function %s", child)
						}
					}
					return false, nil
				}
				for _, dynBrklet := range dynbp.Breaklets {
					dynBrklet.SetCallback(dynCallback)
				}
			}

View on GitHub (pinned to a23773e6c3)

Solutions

  1. Run dlv with elevated capabilities (sudo or CAP_BPF/CAP_PERFMON/CAP_SYS_RESOURCE) as documented for eBPF tracing.
  2. Check kernel version supports BPF ringbuf (>= 5.8) and uprobes are enabled.
  3. Reduce --follow-calls depth to attach fewer probes and stay under per-process uprobe limits.
  4. If authoring Delve code, wrap with %w so the underlying ebpf error is visible: fmt.Errorf("error creating tracepoint in function %s: %w", fn.Name, err).

Example fix

// before
return false, fmt.Errorf("error creating tracepoint in function %s", fn.Name)
// after (preserve root cause)
return false, fmt.Errorf("error creating tracepoint in function %s: %w", fn.Name, err)
Defensive patterns

Strategy: retry

Validate before calling

// pre-flight: verify eBPF tracepoint permission before launching dlv
if os.Geteuid() != 0 {
	out, _ := exec.Command("capsh", "--print").Output()
	if !strings.Contains(string(out), "cap_bpf") {
		log.Fatal("eBPF tracing needs CAP_BPF/CAP_PERFMON; run with sudo or grant capabilities")
	}
}

Type guard

func isTracepointCreateError(err error, fn string) bool {
	return err != nil && strings.Contains(err.Error(), "error creating tracepoint in function "+fn)
}

Try / catch

err := runTrace()
for attempt := 1; err != nil && isTracepointCreateError(err, fnName) && attempt <= 3; attempt++ {
	time.Sleep(time.Duration(attempt) * 500 * time.Millisecond) // let kernel free probes
	err = runTrace()
}
if err != nil { log.Fatalf("tracepoint creation failed: %v", err) }

Prevention

When it happens

Trigger: createFunctionTracepoints(d, fn.Name, rootstr, followCalls) returned an error during the dynCallback in traverse; the callback re-wraps it as 'error creating tracepoint in function %s' without %w.

Common situations: Missing CAP_BPF/CAP_PERFMON or unprivileged BPF disabled; too many uprobes attached (kernel limit hit while following many calls); tracing functions on unsupported pages (e.g. non-Go code that slipped through); kernel without ringbuf support.

Related errors


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