What causes "waiting for target execve failed: %s" in go-delve/delve?

Run the binary standalone first (`./cmd`) to surface exec/ldd errors.

waiting for target execve failed: %s

Error message

waiting for target execve failed: %s

What it means

On FreeBSD, Launch ptrace-follows the child through its execve and then blocks in dbp.wait for the exec stop event. If that wait returns an error, Delve reports "waiting for target execve failed: <err>" — the new program image never reported its initial stop, so symbol loading cannot proceed.

Source

Thrown at pkg/proc/native/proc_freebsd.go:128

			dbp.ctty, err = attachProcessToTTY(process, tty)
			if err != nil {
				return
			}
		}
		if wd != "" {
			process.Dir = wd
		}
		err = process.Start()
	})
	closefn()
	if err != nil {
		return nil, err
	}
	dbp.pid = process.Process.Pid
	dbp.childProcess = true
	_, _, err = dbp.wait(process.Process.Pid, 0)
	if err != nil {
		return nil, fmt.Errorf("waiting for target execve failed: %s", err)
	}
	tgt, err := dbp.initialize(cmd[0], debugInfoDirs)
	if err != nil {
		return nil, err
	}
	return tgt, nil
}

// Attach to an existing process with the given PID. Once attached, if
// the DWARF information cannot be found in the binary, Delve will look
// for external debug files in the directories passed in.
func Attach(pid int, waitFor *proc.WaitFor, debugInfoDirs []string) (*proc.TargetGroup, error) {
	if waitFor.Valid() {
		var err error
		pid, err = WaitFor(waitFor)
		if err != nil {
			return nil, err
		}

View on GitHub (pinned to a23773e6c3)

Solutions

Run the binary standalone first (`./cmd`) to surface exec/ldd errors.
Verify dynamic dependencies with `ldd ./cmd` and install missing libraries.
Check sysctl kern.ptrace / securelevel restrictions on the FreeBSD host.
Confirm the binary architecture matches the host (freebsd-amd64 vs arm64).
Retry the launch if the failure was a transient wait error (EINTR).

Example fix

// before
dlv exec ./app   // fails: missing shared object
// after
ldd ./app        # find missing libs
pkg install <missing-lib>
dlv exec ./app

Defensive patterns

Strategy: validation

Validate before calling

if err := exec.Command(binPath).Run(); err != nil {
    return fmt.Errorf("target does not run standalone: %w", err)
}
// also: ldd binPath to verify all shared objects resolve

Try / catch

tgt, err := proc.Launch(cmd, wd, false, "", [], "", logger)
if err != nil && strings.Contains(err.Error(), "waiting for target execve failed") {
    // run the binary manually to see the exec/dynamic-linker error
}

Prevention

Always run the target standalone before debugging it.
Verify dynamic dependencies with ldd on FreeBSD.
Match binary ABI/arch to the host.
Check kern.ptrace/securelevel restrictions on hardened hosts.

When it happens

Trigger: proc.Launch on FreeBSD when the first wait(pid, 0) after starting the process fails: child died immediately (missing/broken binary, dynamic linker failure), or ptrace permission denied.

Common situations: Launching a binary whose shared libraries are missing (ELF interpreter errors); kern.ptrace security settings (e.g. kern.securelevel, procfs restrictions); launching through a shell wrapper on FreeBSD; binary built for a different ABI.

Related errors

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