go-delve/delve · error

reading NT_FILE header: %v

Error message

reading NT_FILE header: %v

What it means

This error is raised when binary.Read fails to decode the NT_FILE note header (linuxNTFileHdr: count of mapped-file entries plus page-count fields) from the note descriptor. Delve throws it when the descriptor is too short or corrupt, meaning the mapped-file table of the core cannot be parsed.

Source

Thrown at pkg/proc/core/linux_core.go:353

		default:
			return nil, errors.New("unsupported machine type")
		}
		if err := binary.Read(descReader, binary.LittleEndian, note.Desc); err != nil {
			return nil, fmt.Errorf("reading NT_PRSTATUS: %v", err)
		}
	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:

View on GitHub (pinned to a23773e6c3)

Solutions

1. Re-capture the core dump and verify with readelf -n <core> that NT_FILE parses.
2. Use a standard dumper (kernel-generated core or gcore) instead of a custom/trimmed dump tool.
3. Compare the note's Descsz against the expected header+entries size to detect a bad producer.
4. If the NT_FILE note is optional for your analysis, regenerate with a dumper that omits it cleanly rather than truncating.

Example fix

// before
// custom dumper wrote only partial NT_FILE note
desc := buf[:len(buf)/2]
// after
hdrSize := 16 // linuxNTFileHdr size on 64-bit
if len(desc) < hdrSize {
    return fmt.Errorf("NT_FILE note truncated: need %d bytes, have %d", hdrSize, len(desc))
}

// Verify the NT_FILE note is present and self-consistent via readelf output:
out, err := exec.Command("readelf", "-n", corePath).Output()
if err != nil || !bytes.Contains(out, []byte("NT_FILE")) {
    return fmt.Errorf("core %s missing or corrupt NT_FILE note", corePath)
}

When it happens

Trigger: A core file whose NT_FILE note descriptor ends before the header struct is complete; also triggered by corrupted descriptors where Descsz doesn't match the real NT_FILE layout.

Common situations: Truncated or hand-modified core dumps, cores produced by nonstandard dumpers that shrink the NT_FILE note, corrupted CI artifact downloads.

Related errors

• reading NT_FILE entry %v: %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/62eedad6560b0985. Report an issue: GitHub.