go-delve/delve · error

reading debug_info: file index (%d) out of range in compile

Error message

reading debug_info: file index (%d) out of range in compile unit file table at %#x

What it means

Returned by (*compileUnit).filePath (pkg/proc/bininfo.go:3253) when a DIE's file index, after DWARF<5 decrement adjustment, is negative or beyond the CU's line-program FileNames table. This means the DWARF references a file that the debug_line file table does not contain — i.e., inconsistent DWARF between debug_info and debug_line.

Source

Thrown at pkg/proc/bininfo.go:3253

// cuFilePath takes a compilation unit "cu" and a file index reference
// "fileidx" and returns the corresponding file name entry from the
// DWARF line table associated with the unit; "entry" is the offset of
// the attribute where the file reference originated, for logging
// purposes. Return value is the file string and an error value; error
// will be non-nil if the file could not be recovered, perhaps due to
// malformed DWARF.
func (cu *compileUnit) filePath(fileidx int, entry *dwarf.Entry) (string, error) {
	if cu.lineInfo == nil {
		return "", fmt.Errorf("reading debug_info: file reference within a compilation unit without debug_line section at %#x", entry.Offset)
	}
	// File numbering is slightly different before and after DWARF 5;
	// account for this here. See section 6.2.4 of the DWARF 5 spec.
	if cu.Version < 5 {
		fileidx--
	}
	if fileidx < 0 || fileidx >= len(cu.lineInfo.FileNames) {
		return "", fmt.Errorf("reading debug_info: file index (%d) out of range in compile unit file table at %#x", fileidx, entry.Offset)
	}
	return cu.lineInfo.FileNames[fileidx].Path, nil
}

View on GitHub (pinned to a23773e6c3)

Solutions

  1. Rebuild all objects with a consistent DWARF version (e.g. force -gdwarf-4 or -gdwarf-5 uniformly across gcc/cgo flags).
  2. Check for stale third-party .a/.o files compiled with mismatched DWARF and rebuild them from source.
  3. Upgrade Delve — file-index handling across DWARF versions has had fixes; an older Delve may mis-handle DWARF 5 tables.
  4. Inspect the failing CU with `readelf --debug-dump=info` and `--debug-dump=rawline` to confirm the file index vs table size mismatch and identify the offending object.

Example fix

// before: mixed DWARF versions from cgo
go env -w CGO_CFLAGS="-O2"

// after: pin DWARF version for all C bits
go env -w CGO_CFLAGS="-O2 -gdwarf-4"
Defensive patterns

Strategy: validation

Validate before calling

# Check DWARF version consistency across objects in the binary:
readelf --debug-dump=info ./app | grep -m5 "Version:"   # CU versions
readelf --debug-dump=rawline ./app | head -40           # file table vs DIE file indices

Try / catch

if err != nil && strings.Contains(err.Error(), "out of range in compile unit file table") {
    return fmt.Errorf("inconsistent DWARF (file index vs line table); rebuild with uniform -gdwarf-4/-gdwarf-5: %w", err)
}

Prevention

When it happens

Trigger: A DW_AT_decl_file / DW_AT_call_file attribute value that exceeds the number of entries in the CU's file_names list (DWARF 2-4 indices are 1-based, DWARF 5 is 0-based; the code adjusts with fileidx-- for Version<5); mixing object files compiled with different DWARF versions into one binary; a truncated debug_line section.

Common situations: Linking C/C++ or assembly objects compiled with a different DWARF version than the Go objects (e.g. old gcc emitting DWARF 4 into a DWARF 5 link), partial LTO/objcopy processing that rewrote one section but not the other, third-party prebuilt static libraries with stale DWARF.

Related errors


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