golang/go · error
malformed object file
Error message
malformed object file
What it means
Defined as errBuildIDMalformed in buildid.go and returned when ReadFile cannot find a recognizable Go object, archive, or build-id structure in a file. The package first tries the `!<arch>` archive header, `__.PKGDEF`, `go object `, and `build id ` markers; if none line up with the expected layout, the file is treated as malformed.
Source
Thrown at src/cmd/internal/buildid/buildid.go:20
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package buildid
import (
"bytes"
"debug/elf"
"fmt"
"internal/xcoff"
"io"
"io/fs"
"os"
"strconv"
"strings"
)
var (
errBuildIDMalformed = fmt.Errorf("malformed object file")
bangArch = []byte("!<arch>")
pkgdef = []byte("__.PKGDEF")
goobject = []byte("go object ")
buildid = []byte("build id ")
)
// ReadFile reads the build ID from an archive or executable file.
func ReadFile(name string) (id string, err error) {
f, err := os.Open(name)
if err != nil {
return "", err
}
defer f.Close()
buf := make([]byte, 8)
if _, err := f.ReadAt(buf, 0); err != nil {
return "", errView on GitHub (pinned to b6b368adc5)
Solutions
- Clean the build cache: `go clean -cache`.
- Rebuild the affected package from source: `go build -a <pkg>`.
- Verify the file is actually a Go-produced object (e.g. `file <obj>` and inspect for the `go object` magic).
- If reproducible, check for disk space issues, concurrent writers, or failing hardware during the build.
Defensive patterns
Strategy: try-catch
Validate before calling
// before handing an object to buildid.ReadFile, sanity-check the magic:
f, _ := os.Open(obj)
hdr := make([]byte, 8)
_, _ = io.ReadFull(f, hdr)
_ = f.Close()
if !bytes.HasPrefix(hdr, []byte("!<arch>")) && !bytes.HasPrefix(hdr, []byte("\x7fELF")) {
return errors.New("not a recognizable Go object/archive")
} Try / catch
id, err := buildid.ReadFile(obj)
if err != nil {
if errors.Is(err, buildid.ErrBuildIDMalformed) || strings.Contains(err.Error(), "malformed object file") {
// rebuild from source
_ = os.Remove(obj)
}
return err
} Prevention
- Treat build cache as disposable: `go clean -cache` on any unexplained buildid error.
- Don't mix object files across Go versions.
- Avoid kill -9 during compile/link; let steps finish.
When it happens
Trigger: Passing a non-Go object file (random binary, corrupted object, truncated build artifact, foreign-toolchain output) to a buildid function such as ReadFile, ReadFile or the rewrite helpers. Also when a cached object in the build cache is partially written or truncated.
Common situations: Corrupted build cache entries (e.g. after a crash, disk full, or `kill -9` during compile), mixing objects from incompatible Go versions, hand-editing .a files, or pointing the toolchain at a non-Go archive.
Understand the failure class
- Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.
Related errors
- corrupt object file
- read namesize failed: %v
- read descsize failed: %v
- read type failed: %v
- read name failed: %v
AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12).
Data as JSON: /api/errors/ac2d78e485d3cf52.
Report an issue: GitHub.