What causes "non-zero length array with nil base" in go-delve/delve?

Check whether the slice is truly initialized in your program (a nil-backed slice with nonzero len is a program bug).

non-zero length array with nil base

Error message

non-zero length array with nil base

What it means

loadArrayValues requires a non-empty array/slice to have a non-zero Base (the address of the first element). If Len > 0 but Base == 0, the value claims to have elements but points to nil memory, so reading it is impossible and the variable is marked unreadable. This typically reflects a nil or zero-valued slice being evaluated as if it had elements.

Source

Thrown at pkg/proc/variables.go:1732

		TypedefType: godwarf.TypedefType{
			CommonType: chanType.TypedefType.CommonType,
			Type:       pointerTo(newStructType, v.bi.Arch),
		},
		ElemType: chanType.ElemType,
	}
}

func (v *Variable) loadArrayValues(recurseLevel int, cfg LoadConfig) {
	if v.Unreadable != nil {
		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

View on GitHub (pinned to a23773e6c3)

Solutions

Check whether the slice is truly initialized in your program (a nil-backed slice with nonzero len is a program bug).
Inspect the individual header fields: `print lenField`, `print dataPtr` to confirm the inconsistency.
Step to a point where the slice is initialized before evaluating it.
If it came from an unsafe cast, validate that the source memory was populated first.

Example fix

// before
s := *(*[]byte)(unsafe.Pointer(&zeroedHeader)) // len=4, data=nil
print(s)
// after
if hdr.data != 0 { print(s) } else { print("nil data pointer") }

Defensive patterns

Strategy: validation

Validate before calling

if v.Len > 0 && v.Base == 0 {
    // impossible slice header; do not attempt element reads
    return
}

Type guard

func hasValidSliceHeader(v *Variable) bool {
    return v.Len >= 0 && !(v.Base == 0 && v.Len > 0)
}

Try / catch

if v.Unreadable != nil && strings.Contains(v.Unreadable.Error(), "nil base") {
    // treat as uninitialized slice; report header fields instead
    return
}

Prevention

Initialize slices before inspecting them at breakpoints
Validate data pointer != nil when slices come from unsafe casts
Check for program bugs: a nonzero-length slice with nil data is always invalid

When it happens

Trigger: Evaluating a slice whose header says len > 0 but whose data pointer is nil — e.g. a zero-value struct misinterpreted as an initialized slice, reading uninitialized memory, or a type-cast producing an impossible slice header.

Common situations: Inspecting structs before initialization in a crash, evaluating slices cast via unsafe from zeroed memory, debugging programs that crashed mid-initialization, or stale/incorrect variable evaluation in cgo frames.

Related errors

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