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
- Rebuild all objects with a consistent DWARF version (e.g. force -gdwarf-4 or -gdwarf-5 uniformly across gcc/cgo flags).
- Check for stale third-party .a/.o files compiled with mismatched DWARF and rebuild them from source.
- Upgrade Delve — file-index handling across DWARF versions has had fixes; an older Delve may mis-handle DWARF 5 tables.
- 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
- Pin one DWARF version for the whole build (all cgo/C flags and linker inputs).
- Rebuild vendored/third-party static libraries from source instead of using stale prebuilt objects.
- Upgrade Delve when switching to a toolchain emitting newer DWARF (e.g. DWARF 5).
- Sanity-check fresh builds with readelf dumps in CI before shipping debug artifacts.
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
- swiss table type does not have some required fields
- reading debug_info: file reference within a compilation unit
- ErrTypeNotFound
- entry has no location attribute
- ErrNoDebugInfoFound
AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31).
Data as JSON: /api/errors/f93ea745e9d8292c.
Report an issue: GitHub.