go-delve/delve · error

aligning after name: %v

Error message

aligning after name: %v

What it means

readNote wraps any failure from skipPadding (which discards alignment bytes after the note's name field in an ELF core NT_* note) with this message. It means the core-file reader hit EOF or an I/O error while advancing to the 4-byte alignment boundary, so the note cannot be parsed. Delve throws it because a core dump with a truncated note stream cannot yield valid register/process notes.

Source

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

func readNote(r io.ReadSeeker, machineType elf.Machine) (*note, error) {
	// Notes are laid out as described in the SysV ABI:
	// https://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section
	note := &note{}
	hdr := &elfNotesHdr{}

	err := binary.Read(r, binary.LittleEndian, hdr)
	if err != nil {
		return nil, err // don't wrap so readNotes sees EOF.
	}
	note.Type = elf.NType(hdr.Type)

	name := make([]byte, hdr.Namesz)
	if _, err := r.Read(name); err != nil {
		return nil, fmt.Errorf("reading name: %v", err)
	}
	note.Name = string(name)
	if err := skipPadding(r, 4); err != nil {
		return nil, fmt.Errorf("aligning after name: %v", err)
	}
	desc := make([]byte, hdr.Descsz)
	if _, err := r.Read(desc); err != nil {
		return nil, fmt.Errorf("reading desc: %v", err)
	}
	descReader := bytes.NewReader(desc)
	switch note.Type {
	case elf.NT_PRSTATUS:
		switch machineType {
		case _EM_X86_64:
			note.Desc = &linuxPrStatusAMD64{}
		case _EM_AARCH64:
			note.Desc = &linuxPrStatusARM64{}
		case _EM_RISCV:
			note.Desc = &linuxPrStatusRISCV64{}
		case _EM_LOONGARCH:
			note.Desc = &linuxPrStatusLOONG64{}
		default:

View on GitHub (pinned to a23773e6c3)

Solutions

1. Re-capture the core dump, verifying its size matches what the dumping process wrote (no ulimit -c truncation).
2. Check disk space and file transfer integrity (checksum the core file) before opening it in Delve.
3. Verify the file is a complete ELF core (readelf -a <core> parses cleanly) and that the ELF program headers' sizes fit within the file.
4. If the dump is irrecoverable, debug from a re-run of the crash instead of repairing the truncated core.

Example fix

// before
core, _ := os.Open("core")
fi, _ := core.Stat()
// assuming fi.Size() bytes are valid
// after
core, err := os.Open("core")
if err != nil { log.Fatal(err) }
fi, err := core.Stat()
if err != nil { log.Fatal(err) }
// confirm note segments fit in the file before parsing
if elfHeaderNoteOffset+noteSize > fi.Size() {
    log.Fatalf("core file truncated: %d of %d bytes", fi.Size(), expectedSize)
}

// Before running dlv core, verify the ELF core's note data fits in the file:
func validateCore(corePath string) error {
    f, err := os.Open(corePath)
    if err != nil { return err }
    defer f.Close()
    ef, err := elf.NewFile(f)
    if err != nil { return fmt.Errorf("not a valid ELF file: %w", err) }
    if ef.Type != elf.ET_CORE { return fmt.Errorf("%s is not a core dump", corePath) }
    fi, _ := f.Stat()
    for _, p := range ef.Progs {
        end := p.Off + p.Filesz
        if p.Type == elf.PT_NOTE && end > uint64(fi.Size()) {
            return fmt.Errorf("core truncated: PT_NOTE extends to %d > file size %d", end, fi.Size())
        }
    }
    return nil
}

When it happens

Trigger: Opening a truncated or partially written ELF core dump (dlv core <binary> <core>) where the file ends immediately after the note name, before the 4-byte padding; also an underlying io.Reader error from the core file reader (r.Read failing on skipPadding).

Common situations: Core dump cut short by disk-full during dump collection, ulimit -c limits truncating the dump, copying the core file while the process was still dumping, or transferring a multi-GB core with rsync/scp interrupted.

Related errors

• reading desc: %v
• aligning after desc: %v
• unsupported machine type
• error reading thread note header for thread %d: %v
• error reading thread note registers for thread %d: %v

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