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
- Run delve with --log-output=dewire to see stub stdout/stderr and why it exited.
- Verify the target binary and lldb-server match the host architecture (e.g. not running x86 via Rosetta unexpectedly).
- Ensure the chosen listen port/host is free and reachable (check with lsof/netstat).
- Check that LLDB backend (lldb-server) is installed and on PATH.
- 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
- Run with --log-output=dewire to capture stub stderr when launches fail.
- Confirm lldb-server is installed and matches the binary architecture.
- Verify the listen port is free before launching.
- Avoid mismatched architectures (x86 vs arm64, Rosetta) between target and stub.
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
- stub exited while waiting for connection: %v
- debugserver or lldb-server not found: install Xcode's comman
- stub exited while attempting to connect: %v
- direction change with internal breakpoints
- can not start a call injection while running backwards
AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31).
Data as JSON: /api/errors/2842b2ec16ddb300.
Report an issue: GitHub.