go-delve/delve · error

malformed stop packet: %s

Error message

malformed stop packet: %s

What it means

Thrown by parseStopPacket when the two characters after 'T' in a stop reply are not valid hexadecimal, so the signal number cannot be decoded. A stop packet must carry a 2-digit hex signal, e.g. 'T02'. This means the stub sent a structurally invalid stop packet.

Source

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

//	https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/mach/arm/exception.h.auto.html
const (
	_EXC_BREAKPOINT     = 6     // mach exception type for hardware breakpoints
	_EXC_I386_SGL       = 1     // mach exception code for single step on x86, for some reason this is also used for watchpoints
	_EXC_ARM_DA_DEBUG   = 0x102 // mach exception code for debug fault on arm/arm64
	_EXC_ARM_BREAKPOINT = 1     // mach exception code for breakpoint on arm/arm64
)

// executes 'vCont' (continue/step) command
func (conn *gdbConn) parseStopPacket(resp []byte, threadID string, tu *threadUpdater) (repeat bool, sp stopPacket, err error) {
	switch resp[0] {
	case 'T':
		if len(resp) < 3 {
			return false, stopPacket{}, fmt.Errorf("malformed response for vCont %s", string(resp))
		}

		sig, err := strconv.ParseUint(string(resp[1:3]), 16, 8)
		if err != nil {
			return false, stopPacket{}, fmt.Errorf("malformed stop packet: %s", string(resp))
		}
		sp.sig = uint8(sig)
		sp.watchReg = -1
		sp.regs = make(map[uint64]uint64)

		if logflags.GdbWire() && gdbWireFullStopPacket {
			conn.log.Debugf("full stop packet: %s", string(resp))
		}

		var metype int
		medata := make([]uint64, 0, 10)

		parseMachException := func(sp *stopPacket, metype int, medata []uint64) {
			// Debugserver does not report watchpoint stops in the standard way preferring
			// instead the semi-undocumented metype/medata keys.
			// These values also have different meanings depending on the CPU architecture.
			switch conn.goarch {
			case "amd64":

View on GitHub (pinned to a23773e6c3)

Solutions

  1. Inspect the raw wire with gdbwire logging to find what the stub actually sent
  2. Resync or restart the debug session (the packet stream may be desynchronized)
  3. Update the stub/gdbserver to one that emits standard T-packets
  4. Check for a version mismatch between Delve and the target's debug server
Defensive patterns

Strategy: try-catch

Try / catch

repeat, sp, err := conn.parseStopPacket(resp, tid, tu)
if err != nil {
    if strings.Contains(err.Error(), "malformed stop packet") {
        log.Warnf("bad stop packet from stub: %v — resyncing", err)
        return conn.resyncAndRecover()
    }
    return err
}

Prevention

When it happens

Trigger: A vCont reply starting with 'T' whose resp[1:3] bytes are non-hex (e.g. 'T??' or ASCII text where the signal digits should be).

Common situations: Connecting to stubs that emit error text or non-standard replies to continue commands; protocol desync where Delve reads a fragment of a different packet as the stop reply; debugserver/gdbserver version incompatibilities.

Understand the failure class

Related errors


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