go-delve/delve · error

too many transmit attempts

Error message

too many transmit attempts

What it means

ErrTooManyAttempts is returned by the gdbserial connection layer when sending a packet (or an acknowledgement sequence) repeatedly fails after the maximum number of retries. The GDB Remote Serial Protocol transmit path retries on checksum/no-ack failures; exhausting retries means the remote stub is not reliably acknowledging packets.

Source

Thrown at pkg/proc/gdbserial/gdbserver_conn.go:56

	pid int // cache process id

	ack                   bool // when ack is true acknowledgment packets are enabled
	multiprocess          bool // multiprocess extensions are active
	maxTransmitAttempts   int  // maximum number of transmit or receive attempts when bad checksums are read
	threadSuffixSupported bool // thread suffix supported by stub
	isDebugserver         bool // true if the stub is debugserver
	xcmdok                bool // x command can be used to transfer memory
	goarch                string
	goos                  string

	useXcmd       bool // forces writeMemory to use the 'X' command
	newRRCmdStyle bool // forces qRRCmd to use the post-5.8.0 style always

	log logflags.Logger
}

var ErrTooManyAttempts = errors.New("too many transmit attempts")

// GdbProtocolError is an error response (Exx) of Gdb Remote Serial Protocol
// or an "unsupported command" response (empty packet).
type GdbProtocolError struct {
	context string
	cmd     string
	code    string
}

func (err *GdbProtocolError) Error() string {
	cmd := err.cmd
	if len(cmd) > 20 {
		cmd = cmd[:20] + "..."
	}
	if err.code == "" {
		return fmt.Sprintf("unsupported packet %s during %s", cmd, err.context)
	}
	return fmt.Sprintf("protocol error %s during %s for packet %s", err.code, err.context, cmd)

View on GitHub (pinned to a23773e6c3)

Solutions

1. Check that the remote stub (debugserver/gdbserver/qemu) is still alive and the connection is not half-closed
2. Reconnect: restart the debug session or re-dial the remote target
3. Inspect network/serial reliability (latency, packet loss, baud rate) between Delve and the stub
4. Update the remote stub; some versions mishandle ACK mode or large packets

// probe the link before long sessions
conn, err := net.DialTimeout("tcp", addr, 5*time.Second)
if err != nil { return err }
if err := conn.SetDeadline(time.Now().Add(10 * time.Second)); err != nil { return err }

err := doDebugOp()
for attempt := 0; attempt < 3 && err != nil; attempt++ {
    if !errors.Is(err, gdbserial.ErrTooManyAttempts) { break }
    time.Sleep(time.Duration(attempt+1) * 500 * time.Millisecond)
    err = doDebugOp() // or re-dial the connection first
}

When it happens

Trigger: Any gdbserial operation (continue, step, breakpoint set, memory read) that calls conn.sendPacket when the remote target repeatedly fails to ACK or respond, hitting the retry limit in the connection send loop.

Common situations: Flaky serial/TCP link to a remote device (embedded board, qemu); target resets or wedges mid-packet; debugserver crashes while processing a command; baud/latency issues on real serial lines.

Related errors

• qMemoryRegionInfo response wrapped around the address space
• malformed qfThreadInfo response
• could not determine executable path: %v
• malformed qMemoryRegionInfo response packet (start): %v in %
• malformed qMemoryRegionInfo response packet (size): %v in %s

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