go-delve/delve · error
reading NT_FILE entry %v: %v
Error message
reading NT_FILE entry %v: %v
What it means
readNote wraps binary.Read failures when decoding an individual NT_FILE mapped-file entry (start/end/file-ofs addresses) into linuxNTFileEntry. The NT_FILE header said there are data.Count entries, but entry i could not be read from the descriptor — the note is truncated mid-table or the count is wrong.
Source
Thrown at pkg/proc/core/linux_core.go:358
}
case elf.NT_PRPSINFO:
note.Desc = &linuxPrPsInfo{}
if err := binary.Read(descReader, binary.LittleEndian, note.Desc); err != nil {
return nil, fmt.Errorf("reading NT_PRPSINFO: %v", err)
}
case _NT_FILE:
// No good documentation reference, but the structure is
// simply a header, including entry count, followed by that
// many entries, and then the file name of each entry,
// null-delimited. Not reading the names here.
data := &linuxNTFile{}
if err := binary.Read(descReader, binary.LittleEndian, &data.linuxNTFileHdr); err != nil {
return nil, fmt.Errorf("reading NT_FILE header: %v", err)
}
for i := 0; i < int(data.Count); i++ {
entry := &linuxNTFileEntry{}
if err := binary.Read(descReader, binary.LittleEndian, entry); err != nil {
return nil, fmt.Errorf("reading NT_FILE entry %v: %v", i, err)
}
data.entries = append(data.entries, entry)
}
note.Desc = data
case _NT_X86_XSTATE:
if machineType == _EM_X86_64 {
var fpregs amd64util.AMD64Xstate
if err := amd64util.AMD64XstateRead(desc, true, &fpregs, 0); err != nil {
return nil, err
}
note.Desc = &fpregs
}
case _NT_AUXV, elfwriter.DelveHeaderNoteType, elfwriter.DelveThreadNodeType:
note.Desc = desc
case _NT_FPREGSET:
if machineType == _EM_AARCH64 {
err = readFpregsetNote(note, &linutil.ARM64PtraceFpRegs{}, desc[:_ARM_FP_HEADER_START])
} else if machineType == _EM_RISCV {View on GitHub (pinned to a23773e6c3)
Solutions
- Re-dump the core with the standard kernel dumper or gcore and retry dlv core.
- Validate with readelf -n <core>; a truncated NT_FILE note shows up there.
- If using a custom trimmer, recompute the note size (header + Count*entrySize + filename bytes) consistently.
- Sanity-check Count against Descsz before parsing: (Descsz - headerSize) / entrySize >= Count.
Example fix
// before
for i := 0; i < int(data.Count); i++ {
binary.Read(descReader, binary.LittleEndian, entry) // panics/errors at i-th entry
}
// after
avail := (hdr.Descsz - uint64(hdrSize)) / entrySize
if uint64(data.Count) > avail {
return fmt.Errorf("NT_FILE count %d exceeds available entries %d", data.Count, avail)
} Defensive patterns
Strategy: validation
Validate before calling
// Check NT_FILE entry count sanity before debugging (header says Count, Descsz must hold it): // bytesAvailable = Descsz - headerSize // required = Count * entrySize + filenameBytes // if bytesAvailable < required -> core is truncated/corrupt; re-dump.
Prevention
- Reject cores whose note sizes don't add up (validate with readelf -n).
- Avoid third-party tools that rewrite NT_FILE notes in place.
- Capture cores atomically (write to temp + rename) so partially written dumps never circulate.
- Monitor CI artifact storage for interrupted uploads.
When it happens
Trigger: The NT_FILE descriptor contains fewer entry bytes than the header's Count implies (truncated note or bogus Count field), so the loop's i-th binary.Read fails.
Common situations: Cores written by a dumper that set Count too high or truncated entries, corrupted downloads, cores trimmed by post-processing tools that shortened the note but not the header count.
Related errors
- reading NT_FILE header: %v
- reading NT_PRSTATUS: %v
- reading NT_PRPSINFO: %v
- unsupported machine type
- aligning after name: %v
AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31).
Data as JSON: /api/errors/eeb792b897be541b.
Report an issue: GitHub.