malformed qMemoryRegionInfo response packet (name): %s

Error message

malformed qMemoryRegionInfo response packet (name): %s

What it means

This error is returned by memoryRegionInfo when the 'name' field of a qMemoryRegionInfo response is not valid hex-encoded ASCII. The GDB RSP requires optional string fields like the region name to be hex-encoded; decodeHexString failed on the value. Delve rejects the entire response instead of returning a region with a corrupt name.

Source

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

		switch string(key) {
		case "start":
			start, err := strconv.ParseUint(string(value), 16, 64)
			if err != nil {
				return nil, fmt.Errorf("malformed qMemoryRegionInfo response packet (start): %v in %s", err, string(resp))
			}
			mri.start = start
		case "size":
			size, err := strconv.ParseUint(string(value), 16, 64)
			if err != nil {
				return nil, fmt.Errorf("malformed qMemoryRegionInfo response packet (size): %v in %s", err, string(resp))
			}
			mri.size = size
		case "permissions":
			mri.permissions = string(value)
		case "name":
			namestr, ok := decodeHexString(value)
			if !ok {
				return nil, fmt.Errorf("malformed qMemoryRegionInfo response packet (name): %s", string(resp))
			}
			mri.name = namestr
		case "error":
			errstr, ok := decodeHexString(value)
			if !ok {
				return nil, fmt.Errorf("malformed qMemoryRegionInfo response packet (error): %s", string(resp))
			}
			return nil, fmt.Errorf("qMemoryRegionInfo error: %s", errstr)
		}
	}

	return mri, nil
}

// exec executes a message to the stub and reads a response.
// The details of the wire protocol are described here:
//
//	https://sourceware.org/gdb/onlinedocs/gdb/Overview.html#Overview

View on GitHub (pinned to a23773e6c3)

Solutions

Fix the stub to hex-encode the region name (e.g. name:2f6c69622f782e736f for '/lib/x.so')
Compare with the response captured in the error message to confirm the encoding problem
If the name is optional for your use, use a stub build that omits the name field entirely
Patch decodeHexString tolerance is not an option upstream; prefer fixing the server side

Example fix

// stub before (malformed, plain text)
name:/lib/x.so
// stub after (hex-encoded)
name:2f6c69622f782e736f

Defensive patterns

Strategy: validation

Validate before calling

func validHexString(s string) bool {
    if s == "" || len(s)%2 != 0 { return false }
    _, err := hex.DecodeString(s)
    return err == nil
}
// use: if !validHexString(nameField) { /* name is not RSP hex-encoded */ }

Type guard

func regionNameIsHexEncoded(resp []byte) bool {
    for _, kv := range bytes.Split(resp, []byte(",")) {
        parts := bytes.SplitN(kv, []byte(":"), 2)
        if len(parts) == 2 && string(parts[0]) == "name" {
            _, err := hex.DecodeString(string(parts[1]))
            return err == nil
        }
    }
    return false
}

Try / catch

mri, err := conn.memoryRegionInfo(addr)
if err != nil {
    if strings.Contains(err.Error(), "malformed qMemoryRegionInfo response packet (name)") {
        log.Printf("stub sent non-hex-encoded name: %v", err)
        mri = &memoryRegionInfo{} // proceed without name
    } else {
        return err
    }
}

Prevention

Hex-encode all string-valued fields in custom stub implementations (name, error)
Test stubs against real gdbserver behavior for optional string fields
Omit optional fields entirely rather than sending them in the wrong encoding
Review GDB RSP documentation for qMemoryRegionInfo field encoding rules

When it happens

Trigger: Calling memory region info queries via the gdbserial backend when the stub's qMemoryRegionInfo reply contains 'name:<value>' where value is not a valid hex string (odd-length hex, non-hex characters, or raw unencoded text).

Common situations: Stubs that send the mapping name as plain text (e.g. name:/lib/x.so) instead of hex-encoding it, stubs that send name: with an empty or binary payload, or protocol translations proxies that alter the field.

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/ad1f92b25cf5a5af. Report an issue: GitHub.