What causes "regexp compile error: %v" in go-delve/delve?

Verify the pid passed to attach is a positive valid int within platform range.

regexp compile error: %v

Error message

regexp compile error: %v

What it means

While extracting the process name from /proc/<pid>/stat, delve compiles the regexp "<pid>\\s*\\((.*)\\)". If regexp.Compile fails, this error is returned. Because the pattern is generated from an integer pid, compile failure is practically a defect or corrupted pid value rather than a user input problem.

Source

Thrown at pkg/proc/native/proc_linux.go:284

	return 0, nil
}

func initialize(dbp *nativeProcess) (string, error) {
	comm, err := os.ReadFile(fmt.Sprintf("/proc/%d/comm", dbp.pid))
	if err == nil {
		// removes newline character
		comm = bytes.TrimSuffix(comm, []byte("\n"))
	}

	if len(comm) <= 0 {
		stat, err := os.ReadFile(fmt.Sprintf("/proc/%d/stat", dbp.pid))
		if err != nil {
			return "", fmt.Errorf("could not read proc stat: %v", err)
		}
		expr := fmt.Sprintf("%d\\s*\\((.*)\\)", dbp.pid)
		rexp, err := regexp.Compile(expr)
		if err != nil {
			return "", fmt.Errorf("regexp compile error: %v", err)
		}
		match := rexp.FindSubmatch(stat)
		if match == nil {
			return "", fmt.Errorf("no match found using regexp '%s' in /proc/%d/stat", expr, dbp.pid)
		}
		comm = match[1]
	}
	dbp.os.comm = strings.ReplaceAll(string(comm), "%", "%%")

	return getCmdLine(dbp.pid), nil
}

func (dbp *nativeProcess) GetBufferedTracepoints() []ebpf.RawUProbeParams {
	if dbp.os.ebpf == nil {
		return nil
	}
	return dbp.os.ebpf.GetBufferedTracepoints()
}

View on GitHub (pinned to a23773e6c3)

Solutions

Verify the pid passed to attach is a positive valid int within platform range.
Update delve — with a stock build this error indicates a bug in the calling path.
If you patched the source, ensure interpolated values are integers and pattern metacharacters are escaped.
Capture the underlying regexp error message in the report (%v includes the syntax error position) to identify the malformed input.

Example fix

// before
pid := someUserString // later attached after unchecked conversion

// after
pid, err := strconv.Atoi(pidStr)
if err != nil || pid <= 0 {
    return fmt.Errorf("invalid pid %q", pidStr)
}

Defensive patterns

Strategy: validation

Validate before calling

// validate pid input before any attach path
func validPid(p int) bool { return p > 0 && p <= 1<<31-1 }

Try / catch

err := debugger.Attach(pid, nil)
if err != nil && strings.Contains(err.Error(), "regexp compile error") {
    return fmt.Errorf("internal error or bad pid %d: %w", pid, err)
}

Prevention

Always pass positive integer pids from validated input.
On a stock delve build this error signals a bug — report it with the underlying regexp message.
If patching delve, never interpolate unescaped user strings into patterns.

When it happens

Trigger: initialize's comm-extraction fallback builds the regexp from dbp.pid and regexp.Compile returns an error — in practice only possible with malformed pid input (negative/overflowing) since the base pattern is always valid Go regexp syntax.

Common situations: Effectively never hit by real users on Linux with valid pids; would surface from library misuse embedding a bogus pid, or from a modified delve source that interpolates unescaped user data into the expression.

Related errors

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