go-delve/delve · error

memory range at %#x of size %#x is past the end of file, whi

Error message

memory range at %#x of size %#x is past the end of file, while %s

What it means

While reading a memory list stream, each entry gives a target address and a size, and the reader slices buf.buf[baseOff:baseOff+sz]. If that range lies outside the file, the dump is internally inconsistent and parsing stops with this error. It is the memory-range sibling of the location/string bounds checks and signals a truncated or corrupt minidump.

Source

Thrown at pkg/proc/core/minidump/minidump.go:614

// readMemory64List reads a _MINIDUMP_MEMORY64_LIST structure, containing
// the description of the process memory.
// See: https://docs.microsoft.com/en-us/windows/win32/api/minidumpapiset/ns-minidumpapiset-minidump_memory64_list
// And: https://docs.microsoft.com/en-us/windows/win32/api/minidumpapiset/ns-minidumpapiset-minidump_memory_descriptor
func readMemory64List(mdmp *Minidump, buf *minidumpBuf, logfn func(fmt string, args ...any)) {
	rangesNum := buf.u64()
	baseOff := int(buf.u64())
	if buf.err != nil {
		return
	}

	for i := range rangesNum {
		addr := buf.u64()
		sz := buf.u64()

		end := baseOff + int(sz)
		if baseOff >= len(buf.buf) || end > len(buf.buf) {
			buf.err = fmt.Errorf("memory range at %#x of size %#x is past the end of file, while %s", baseOff, sz, buf.ctx)
			return
		}

		mdmp.addMemory(addr, buf.buf[baseOff:end])

		if logfn != nil {
			logfn("\tMemory %d addr:%#x size:%#x FileOffset:%#x", i, addr, sz, baseOff)
		}

		baseOff = end
	}
}

func readMemoryInfoList(mdmp *Minidump, buf *minidumpBuf, logfn func(fmt string, args ...any)) {
	startOff := buf.off
	sizeOfHeader := int(buf.u32())
	sizeOfEntry := int(buf.u32())
	numEntries := buf.u64()

View on GitHub (pinned to a23773e6c3)

Solutions

  1. Re-acquire the minidump and verify completeness (file size on producer vs consumer).
  2. Inspect with dumpchk/WinDbg to see which memory ranges are missing.
  3. Recopy or re-download the file; compare SHA-256 before and after transfer.
  4. If dumps are routinely truncated, increase dump-writing timeout or write full dumps synchronously before the process exits.

Example fix

// before
core, err := proc.LoadMiniDumpFile("cut.dmp", nil, 0) // memory range at 0x3f0000 of size 0x1000 is past the end of file

// after: check the transfer completed
if got, want := sizeOf("cut.dmp"), sizeOnServer("cut.dmp"); got != want {
    reDownload("cut.dmp")
}
Defensive patterns

Strategy: validation

Validate before calling

func memoryRangesFit(path string) error {
    buf, err := os.ReadFile(path)
    if err != nil { return err }
    // iterate Memory(List|64)Stream descriptors; each baseOff+sz must satisfy baseOff+sz <= len(buf)
    return checkMemoryDescriptors(buf)
}

Try / catch

core, err := proc.LoadMiniDumpFile(path, logfn, 0)
if err != nil {
    if strings.Contains(err.Error(), "memory range at") {
        return fmt.Errorf("dump %s is missing memory data (truncated); re-capture: %w", path, err)
    }
    return err
}

Prevention

When it happens

Trigger: proc.LoadMiniDumpFile parsing a MemoryListStream/Memory64ListStream where a range's start offset (baseOff) is at or beyond the file length, or baseOff+size exceeds it.

Common situations: Dumps truncated during collection (process died mid-MiniDumpWriteDump), uploads cut short, filesystem issues, or corrupted archives where the memory stream region was lost.

Related errors


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