What causes "unexpected response for vCont %c" in go-delve/delve?

Check the wire log to see the actual first character and identify the stub's error reply

unexpected response for vCont %c

Error message

unexpected response for vCont %c

What it means

Thrown by parseStopPacket when the vCont reply starts with a character other than the supported 'T', 'S', 'W', 'X', 'N', or 'O' responses. Delve received a first byte it does not know how to interpret as a stop/exit/output packet, so it reports the offending character.

Source

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

		status, _ := strconv.ParseUint(string(resp[1:semicolon]), 16, 8)
		return false, stopPacket{}, proc.ErrProcessExited{Pid: conn.pid, Status: int(status)}

	case 'N':
		// we were singlestepping the thread and the thread exited
		sp.threadID = threadID
		return false, sp, nil

	case 'O':
		data := make([]byte, 0, len(resp[1:])/2)
		for i := 1; i < len(resp); i += 2 {
			n, _ := strconv.ParseUint(string(resp[i:i+2]), 16, 8)
			data = append(data, uint8(n))
		}
		os.Stdout.Write(data)
		return true, sp, nil

	default:
		return false, sp, fmt.Errorf("unexpected response for vCont %c", resp[0])
	}
}

const ctrlC = 0x03 // the ASCII character for ^C

// executes a ctrl-C on the line
func (conn *gdbConn) sendCtrlC() error {
	conn.log.Debug("<- interrupt")
	_, err := conn.conn.Write([]byte{ctrlC})
	return err
}

// queryProcessInfo executes a qProcessInfoPID (if pid != 0) or a qProcessInfo (if pid == 0)
func (conn *gdbConn) queryProcessInfo(pid int) (map[string]string, error) {
	conn.outbuf.Reset()
	if pid != 0 {
		fmt.Fprintf(&conn.outbuf, "$qProcessInfoPID:%d", pid)
	} else {

View on GitHub (pinned to a23773e6c3)

Solutions

Check the wire log to see the actual first character and identify the stub's error reply
Verify the stub supports vCont ('vCont?' query); fall back to continue/step packets if not
Restart the debug session to clear protocol desync
Upgrade the stub or Delve if the reply is a valid-but-unsupported packet type

Defensive patterns

Strategy: try-catch

Validate before calling

// Confirm vCont support before issuing continue/step:
resp, err := conn.exec([]byte("vCont?"), "vCont support")
if err != nil || !bytes.Contains(resp, []byte("c")) {
    return errors.New("stub does not support vCont; use legacy continue")
}

Try / catch

if _, _, err := conn.parseStopPacket(resp, tid, tu); err != nil && strings.Contains(err.Error(), "unexpected response for vCont") {
    // stub probably replied with an error packet; inspect and fall back
    log.Warnf("vCont rejected: %q", string(resp))
    return legacyContinue()
}

Prevention

Query 'vCont?' before using vCont with a new stub
Watch for 'E' error packets in wire logs during integration
Resynchronize the connection after any unexpected first-byte reply
Test continue/step against your stub before automation

When it happens

Trigger: conn.exec of vCont returns a reply whose resp[0] is not a recognized packet type — e.g. an 'E' error packet, an empty 'OK', or text where a stop packet was expected.

Common situations: Stub rejecting the vCont command (replying with an error packet); stubs lacking vCont support that answered with an error string; protocol desynchronization reading a stale packet; unsupported thread actions requested.

Related errors

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