breakpoint name %q could not be parsed as a function. name m

Error message

breakpoint name %q could not be parsed as a function. name must be in the format 'funcName', 'funcName:line' or 'fileName:line'

What it means

The DAP client requested a function breakpoint whose 'name' could not be resolved to a single function base. Delve only supports function breakpoints at plain function names, 'funcName:line' or 'fileName:line' locations whose parse yields a NormalLocationSpec with a FuncBase; regex or other location forms are rejected.

Source

Thrown at service/dap/server.go:1869

		want := request.Arguments.Breakpoints[i]
		return &bpMetadata{
			name:         fmt.Sprintf("%s Name=%s", functionBpPrefix, want.Name),
			condition:    want.Condition,
			hitCondition: want.HitCondition,
			logMessage:   "",
		}
	}, func(i int) (*bpLocation, error) {
		want := request.Arguments.Breakpoints[i]
		// Set the function breakpoint
		spec, err := locspec.Parse(want.Name)
		if err != nil {
			return nil, err
		}
		if loc, ok := spec.(*locspec.NormalLocationSpec); !ok || loc.FuncBase == nil {
			// Other locations do not make sense in the context of function breakpoints.
			// Regex locations are likely to resolve to multiple places and offset locations
			// are only meaningful at the time the breakpoint was created.
			return nil, fmt.Errorf("breakpoint name %q could not be parsed as a function. name must be in the format 'funcName', 'funcName:line' or 'fileName:line'", want.Name)
		}

		if want.Name[0] == '.' {
			return nil, errors.New("breakpoint names that are relative paths are not supported")
		}
		// Find the location of the function name. CreateBreakpoint requires the name to include the base
		// (e.g. main.functionName is supported but not functionName).
		// We first find the location of the function, and then set breakpoints for that location.
		var locs []api.Location
		locs, err = s.debugger.FindLocationSpec(-1, 0, 0, want.Name, spec, true, s.args.substitutePathClientToServer)
		if err != nil {
			return nil, err
		}
		if len(locs) == 0 {
			return nil, err
		}
		if len(locs) > 1 {
			s.config.log.Debugf("multiple locations found for %s", want.Name)

View on GitHub (pinned to a23773e6c3)

Solutions

Use a plain function name, e.g. 'main.main' or 'pkg.Type.Method'
Use 'funcName:line' to break at a line within the function
Use a regular (line) breakpoint at fileName:line instead of a function breakpoint if you do not target a function
Avoid relative paths (names starting with '.') — these are also unsupported

Example fix

// before (DAP setBreakpoints on functions)
{"breakpoints":[{"name":"foo.*:12"}]}
// after
{"breakpoints":[{"name":"main.foo"}]}

Defensive patterns

Strategy: validation

Validate before calling

var nameRe = regexp.MustCompile(`^[^\s]+(:\d+)?$`)
func validFunctionBPName(n string) bool { return nameRe.MatchString(n) && !strings.HasPrefix(n, ".") }

Try / catch

if err := setFunctionBreakpoints(names); err != nil { if strings.Contains(err.Error(), "could not be parsed as a function") { /* fall back to line breakpoints */ } return err }

Prevention

Only send plain function names or funcName:line for function breakpoints
Use line breakpoints (setBreakpoints with source) for file:line targets
Never start names with '.' (relative paths unsupported)

When it happens

Trigger: setBreakpoints request with type 'function' where the breakpoint name parses to a non-Normal locspec, or a NormalLocationSpec whose FuncBase is nil (e.g. a bare file:line without a function, or a regex location).

Common situations: IDE users typing regex-like patterns or plain file:line into a 'function breakpoint' field, or tools sending fully qualified paths with line numbers that do not denote a function entry.

Related errors

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