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
- Print the slice header fields (ptr, len, cap) individually to confirm the base address and length are sane
- Re-run the program under the debugger from a clean start to rule out memory corruption
- Rebuild with matching source/binary so DWARF element types (and thus stride) are correct
- 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
- Print slice ptr/len/cap individually first when corruption is suspected
- Cap MaxArrayValues in loadConfig to avoid huge stride*count ranges
- Investigate memory corruption with watchpoints before re-evaluating
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
- unreadable length: %v
- len must be less than or equal to %d
- short read
- can not continue execution of core process
- can not change register values of core process
AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31).
Data as JSON: /api/errors/ab467923446d1256.
Report an issue: GitHub.