go-delve/delve · error

could not connect

Error message

could not connect

What it means

Listen() launches the debugger stub (e.g. lldb-server) and waits for either an incoming TCP connection on the accept channel or process exit. If the process died before a connection could be accepted (conn == nil), 'could not connect' is returned.

Source

Thrown at pkg/proc/gdbserial/gdbserver.go:296

	}

	return p
}

// Listen waits for a connection from the stub.
func (p *gdbProcess) Listen(listener net.Listener, path, cmdline string, pid int, debugInfoDirs []string, stopReason proc.StopReason) (*proc.TargetGroup, error) {
	acceptChan := make(chan net.Conn)

	go func() {
		conn, _ := listener.Accept()
		acceptChan <- conn
	}()

	select {
	case conn := <-acceptChan:
		listener.Close()
		if conn == nil {
			return nil, errors.New("could not connect")
		}
		return p.Connect(conn, path, cmdline, pid, debugInfoDirs, stopReason)
	case status := <-p.waitChan:
		listener.Close()
		if err := checkRosettaExpensive(); err != nil {
			return nil, err
		}
		return nil, fmt.Errorf("stub exited while waiting for connection: %v", status)
	}
}

// Dial attempts to connect to the stub.
func (p *gdbProcess) Dial(addr string, path, cmdline string, pid int, debugInfoDirs []string, stopReason proc.StopReason) (*proc.TargetGroup, error) {
	for {
		conn, err := net.Dial("tcp", addr)
		if err == nil {
			return p.Connect(conn, path, cmdline, pid, debugInfoDirs, stopReason)
		}

View on GitHub (pinned to a23773e6c3)

Solutions

  1. Run delve with --log-output=dewire to see stub stdout/stderr and why it exited.
  2. Verify the target binary and lldb-server match the host architecture (e.g. not running x86 via Rosetta unexpectedly).
  3. Ensure the chosen listen port/host is free and reachable (check with lsof/netstat).
  4. Check that LLDB backend (lldb-server) is installed and on PATH.
  5. Try a different listen address (e.g. 127.0.0.1:0) to rule out networking issues.

Example fix

// before
dlv connect localhost:4040   // fails: could not connect
// after
lsof -i :4040                # find conflicting process
dlv connect 127.0.0.1:0      # let delve pick a free port
Defensive patterns

Strategy: retry

Validate before calling

ln, err := net.Listen("tcp", addr)
if err != nil { return fmt.Errorf("port %s unavailable: %w", addr, err) }
ln.Close()

Try / catch

conn, err := gdbserial.Listen(addr, ...)
if err != nil {
    if strings.Contains(err.Error(), "could not connect") {
        // retry or inspect stub logs
    }
}

Prevention

When it happens

Trigger: p.waitChan receives exit (stub crashed/exited) before any connection arrives, so acceptChan delivers nil and Listen returns errors.New("could not connect").

Common situations: lldb-server binary missing or wrong architecture, port already used/firewalled, stub crashes on startup (bad DYLD/PATH env), macOS Rosetta problems, or the target binary fails to exec inside the stub.

Related errors


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