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
- Re-acquire the minidump and verify completeness (file size on producer vs consumer).
- Inspect with dumpchk/WinDbg to see which memory ranges are missing.
- Recopy or re-download the file; compare SHA-256 before and after transfer.
- 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
- Use synchronous full-dump capture and verify completion before shipping.
- Monitor dump collector timeouts - partial dumps are the top cause of this error.
- Keep a manifest of expected dump sizes and compare on receipt.
- Fail fast in pipelines on size mismatch instead of attempting analysis.
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
- location starting at %#x of size %#x is past the end of file
- string starting at %#x of size %#x is past the end of file,
- minidump %s truncated at offset %#x while %s
- unsupported architecture %s
AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31).
Data as JSON: /api/errors/eeef509160b2855f.
Report an issue: GitHub.