go-delve/delve · error

bad array base address %#x

Error message

bad array base address %#x

What it means

Before reading array elements Delve checks that computing Base + stride*count does not overflow the uint64 address space. If it wraps (an end address below the base), the array base address is deemed bogus and the array is marked unreadable.

Source

Thrown at pkg/proc/variables.go:1742

		return
	}
	if v.Len < 0 {
		//lint:ignore ST1005 backwards compatibility
		v.Unreadable = errors.New("Negative array length")
		return
	}
	if v.Base == 0 && v.Len > 0 {
		v.Unreadable = errors.New("non-zero length array with nil base")
		return
	}

	count := v.Len
	// Cap number of elements
	if (v.Flags&variableTrustLen == 0) && (count > int64(cfg.MaxArrayValues)) {
		count = int64(cfg.MaxArrayValues)
	}
	if v.Base+uint64(v.stride*count) < v.Base {
		v.Unreadable = fmt.Errorf("bad array base address %#x", v.Base)
		return
	}

	if v.stride < maxArrayStridePrefetch {
		v.mem = cacheMemory(v.mem, v.Base, int(v.stride*count))
	}

	errcount := 0

	mem := v.mem
	if v.Kind != reflect.Array {
		mem = DereferenceMemory(mem)
	}

	for i := int64(0); i < count; i++ {
		fieldvar := v.newVariable("", uint64(int64(v.Base)+(i*v.stride)), v.fieldType, mem)
		fieldvar.loadValueInternal(recurseLevel+1, cfg)

View on GitHub (pinned to a23773e6c3)

Solutions

  1. Print the slice header fields (ptr, len, cap) individually to confirm the base address and length are sane
  2. Re-run the program under the debugger from a clean start to rule out memory corruption
  3. Rebuild with matching source/binary so DWARF element types (and thus stride) are correct
  4. If corruption is real, investigate the program's memory writes (use watchpoints on the slice header)
Defensive patterns

Strategy: validation

Validate before calling

// Validate slice header sanity before printing large arrays
if v.Base == 0 || v.Len <= 0 || v.Len > maxSaneLen { /* treat as corrupted */ }

Type guard

func saneArray(v *proc.Variable) bool {
    return v.Unreadable == nil && v.Base != 0 && v.Len > 0 && v.stride > 0 && v.stride < 1<<20
}

Prevention

When it happens

Trigger: Printing an array/slice whose stride*Len is huge (corrupted Len or stride from bad DWARF), or whose Base address is garbage from uninitialized/corrupted memory.

Common situations: Debugging memory-corrupted programs; evaluating slices in core dumps with truncated/mismatched debug info giving wrong element stride; printing a slice variable whose header was clobbered by a buffer overflow.

Related errors


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