go-delve/delve · error

maximum len exceeded (%d) reading %s

Error message

maximum len exceeded (%d) reading %s

What it means

Inside threadsFromDelveNotes, readBytes reads a uint16 length then that many bytes; when a caller passes maxlen > 0 and the encoded length exceeds it, parsing stops with 'maximum len exceeded'. This guards against corrupt lengths allocating huge or bogus buffers for register names (max 20) and values (max 2048).

Source

Thrown at pkg/proc/core/delve_core.go:100

		read(&th.regs.gaddr)

		var n uint32
		read(&n)

		if readerr != nil {
			return nil, fmt.Errorf("error reading thread note header for thread %d: %v", th.id, readerr)
		}

		th.regs.slice = make([]proc.Register, n)

		readBytes := func(maxlen uint16, kind string) []byte {
			if readerr != nil {
				return nil
			}
			var len uint16
			read(&len)
			if maxlen > 0 && len > maxlen {
				readerr = fmt.Errorf("maximum len exceeded (%d) reading %s", len, kind)
				return nil
			}
			if readerr != nil {
				return nil
			}
			buf := make([]byte, len)
			_, readerr = body.Read(buf)
			return buf
		}

		for i := 0; i < int(n); i++ {
			name := string(readBytes(20, "register name"))
			value := readBytes(2048, "register value")
			th.regs.slice[i] = proc.Register{Name: name, Reg: op.DwarfRegisterFromBytes(value)}
			if readerr != nil {
				return nil, fmt.Errorf("error reading thread note registers for thread %d: %v", th.id, readerr)
			}
		}

View on GitHub (pinned to a23773e6c3)

Solutions

1. Regenerate the core dump with delve to restore a well-formed note stream.
2. Check for earlier corruption/misalignment in the note (one bad length shifts all subsequent reads).
3. Verify the file was not converted (e.g. compression or text-mode transfer) which alters bytes.
4. Confirm the writer and reader use the same delve note layout version.

Example fix

// symptom in stream
len=0xFFFF followed by garbage // exceeds maxlen 20 for register name
// fix by regenerating
$ dlv core <exe> <core>  # after re-dumping a valid core

// Pre-scan thread notes: every length field must respect the caps
if nameLen > 20 || valLen > 2048 {
	return fmt.Errorf("implausible register field lengths name=%d val=%d; core likely corrupt", nameLen, valLen)
}

When it happens

Trigger: readLinuxOrPlatformIndependentCore -> threadsFromDelveNotes: a register name field encodes len > 20, or a register value field encodes len > 2048, in the thread note.

Common situations: Byte-stream misalignment from an earlier bad length or corrupted note; a non-delve writer producing differently framed note data; endianness mismatch making the uint16 length look huge.

Related errors

• short read
• can not continue execution of core process
• can not change register values of core process
• unrecognized core format
• cannot write a breakpoint to a core file

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