What causes "can not parse checkpoint response %q" in go-delve/delve?

Verify the stub supports checkpoints (test `checkpoint` in native gdb against the same target first)

can not parse checkpoint response %q

Error message

can not parse checkpoint response %q

What it means

Delve's Checkpoint command sends the gdb 'checkpoint' packet and expects a reply starting with the known prefix ("Checkpoint "). If the reply does not have that prefix, the response cannot be parsed and this error is returned with the raw response quoted.

Source

Thrown at pkg/proc/gdbserial/gdbserver.go:1184

	return strings.TrimSpace(event), nil
}

const (
	checkpointPrefix = "Checkpoint "
)

// Checkpoint creates a checkpoint from which you can restart the program.
func (p *gdbProcess) Checkpoint(where string) (int, error) {
	if p.tracedir == "" {
		return -1, proc.ErrNotRecorded
	}
	resp, err := p.conn.qRRCmd("checkpoint", where)
	if err != nil {
		return -1, err
	}

	if !strings.HasPrefix(resp, checkpointPrefix) {
		return -1, fmt.Errorf("can not parse checkpoint response %q", resp)
	}

	idstr := resp[len(checkpointPrefix):]
	space := strings.Index(idstr, " ")
	if space < 0 {
		return -1, fmt.Errorf("can not parse checkpoint response %q", resp)
	}
	idstr = idstr[:space]

	cpid, err := strconv.Atoi(idstr)
	if err != nil {
		return -1, err
	}
	return cpid, nil
}

// Checkpoints returns a list of all checkpoints set.
func (p *gdbProcess) Checkpoints() ([]proc.Checkpoint, error) {

View on GitHub (pinned to a23773e6c3)

Solutions

Verify the stub supports checkpoints (test `checkpoint` in native gdb against the same target first)
Use gdbserver (not lldb-server/debugserver) when checkpoints are required
Check the quoted response %q in the error to see what the stub actually returned and adapt
Use rr's native checkpoint interface (rr checkpoints) instead of the Delve gdbserial path if the stub differs

Defensive patterns

Strategy: type-guard

Validate before calling

// confirm stub supports checkpoints before calling:
supportsCheckpoints := func(stubName string) bool {
    return strings.Contains(stubName, "gdbserver") || strings.Contains(stubName, "rr")
}

Try / catch

id, err := proc.Checkpoint(where)
if err != nil && strings.Contains(err.Error(), "can not parse checkpoint response") {
    // stub lacks gdb-format checkpoint support; surface to user
    return fmt.Errorf("checkpoints unsupported by this stub: %w", err)
}

Prevention

Use gdbserver or rr when checkpoints are needed
Test the 'checkpoint' packet against your stub before exposing the feature
Do not enable checkpoint UI for lldb-server/debugserver backends
Log raw stub replies to diagnose format drift early

When it happens

Trigger: Calling Checkpoint against a stub that does not implement checkpoints but returns an error-style or unrecognized reply to the 'checkpoint' command instead of the gdb-remote format 'Checkpoint N at ...'.

Common situations: Using checkpoint/reverse-continue features against gdbserver builds without checkpoint support, or against stubs (lldb-server, debugserver, rr variants) that reply with an error string like 'E01' or a custom message.

Related errors

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