What causes "malformed response for vCont %s" in go-delve/delve?

Check the physical/serial/network link for truncation and reconnect to the target

malformed response for vCont %s

Error message

malformed response for vCont %s

What it means

Thrown by gdbConn.parseStopPacket when the reply to a vCont (continue/step) command starts with 'T' (a stop packet) but has fewer than 3 bytes, so the two hex signal digits cannot be parsed. A valid T stop packet must look like 'T05thread:...' — anything shorter is truncated garbage. Delve treats this as a corrupt response from the remote stub.

Source

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

// Mach exception codes used to decode metype/medata keys in stop packets (necessary to support watchpoints with debugserver).
// See:
//
//	https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/mach/exception_types.h.auto.html
//	https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/mach/i386/exception.h.auto.html
//	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) {

View on GitHub (pinned to a23773e6c3)

Solutions

Check the physical/serial/network link for truncation and reconnect to the target
Restart the debug session; the stub's protocol state may be corrupted
Verify the stub fully implements the GDB remote stop-packet format
Capture wire logs (dlv --log --log-output=gdbwire) and inspect the raw packet

Defensive patterns

Strategy: retry

Validate before calling

// Verify stub health before continuing:
resp, err := conn.exec([]byte("?"), "halt reason")
if err != nil || len(resp) < 3 || resp[0] != 'T' && resp[0] != 'S' {
    return fmt.Errorf("stub not producing valid stop packets")
}

Try / catch

repeat, sp, err := conn.parseStopPacket(resp, tid, tu)
if err != nil && strings.Contains(err.Error(), "malformed response for vCont") {
    // reconnect once and retry the continue
    conn.close()
    return reconnectAndContinue()
}

Prevention

Use a reliable transport (TCP instead of lossy serial) where possible
Check cabling/serial baud rate when debugging over UART
Run with --log-output=gdbwire to catch truncation early
Restart the session after any malformed-packet error; state may be desynced

When it happens

Trigger: conn.exec of a vCont;c/vCont;s command returns a reply of exactly 'T', 'T' plus one char, or an empty 'T'-prefixed response — i.e. the stub sent a truncated stop packet.

Common situations: Flaky serial/network connection dropping bytes mid-packet; buggy or half-implemented stubs that emit bare 'T'; race where the connection is closed while the stop reply is in flight.

Understand the failure class

Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

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