{"record":{"id":"3320a59b15c33f94","repo":"golang/go","slug":"cannot-find-text-section","errorCode":null,"errorMessage":"cannot find __text section","messagePattern":"cannot find __text section","errorType":"exception","errorClass":"fs.PathError","httpStatus":null,"severity":"error","filePath":"src/cmd/internal/buildid/note.go","lineNumber":196,"sourceCode":"// Sadly, that's not guaranteed to hold the note, because there is an arbitrary amount\n// of other junk placed in the file ahead of the main text.\nfunc readMacho(name string, f *os.File, data []byte) (buildid string, err error) {\n\t// If the data we want has already been read, don't worry about Mach-O parsing.\n\t// This is both an optimization and a hedge against the Mach-O parsing failing\n\t// in the future due to, for example, the name of the __text section changing.\n\tif b, err := readRaw(name, data); b != \"\" && err == nil {\n\t\treturn b, err\n\t}\n\n\tmf, err := macho.NewFile(f)\n\tif err != nil {\n\t\treturn \"\", &fs.PathError{Path: name, Op: \"parse\", Err: err}\n\t}\n\n\tsect := mf.Section(\"__text\")\n\tif sect == nil {\n\t\t// Every binary has a __text section. Something is wrong.\n\t\treturn \"\", &fs.PathError{Path: name, Op: \"parse\", Err: fmt.Errorf(\"cannot find __text section\")}\n\t}\n\n\t// It should be in the first few bytes, but read a lot just in case,\n\t// especially given our past problems on OS X with the build ID moving.\n\t// There shouldn't be much difference between reading 4kB and 32kB:\n\t// the hard part is getting to the data, not transferring it.\n\tn := sect.Size\n\tif n > uint64(readSize) {\n\t\tn = uint64(readSize)\n\t}\n\tbuf := make([]byte, n)\n\tif _, err := f.ReadAt(buf, int64(sect.Offset)); err != nil {\n\t\treturn \"\", err\n\t}\n\n\treturn readRaw(name, buf)\n}\n","sourceCodeStart":178,"sourceCodeEnd":214,"githubUrl":"https://github.com/golang/go/blob/b6b368adc57c96c3151d224d172029f233ead2c3/src/cmd/internal/buildid/note.go#L178-L214","documentation":"Returned by the Mach-O build-id reader when mf.Section(\"__text\") returns nil. Every Mach-O executable has a __text section containing executable instructions; its absence means the file is not a well-formed Mach-O binary or is missing the text segment, so the Go build ID (embedded near the start of __text) cannot be located.","triggerScenarios":"Calling the Mach-O path of buildid (triggered for darwin/amd64 and darwin/arm64 binaries) on a file that macho.NewFile parsed but which lacks a __text section — e.g. a Mach-O object file, a relocatable bundle, a stub, or a corrupt executable.","commonSituations":"Pointing the toolchain at a Mach-O object (.o) rather than an executable, a binary stripped of its text segment, a corrupt download, or a non-Go Mach-O file that happens to enter this code path.","solutions":["Confirm the input is a complete darwin executable produced by the Go linker.","Rebuild the binary: `go build` for GOOS=darwin.","Re-download if the file was transferred incompletely.","Check the file with `file <bin>` and `otool -L <bin>` to validate Mach-O structure."],"exampleFix":null,"handlingStrategy":"validation","validationCode":"// before reading a Mach-O build id, confirm it is an executable with __text:\nmf, err := macho.Open(bin)\nif err != nil { return err }\nif mf.Section(\"__text\") == nil {\n    return errors.New(\"not a Mach-O executable (no __text)\")\n}","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Pass Mach-O executables (.dylib/exe), not .o object files, to build-id readers.","Validate with `file <bin>` on darwin before processing.","Re-download incomplete darwin artifacts."],"tags":["buildid","mach-o","darwin","binary","corruption"],"backgroundTag":null,"analyzedSha":"b6b368adc57c96c3151d224d172029f233ead2c3","analyzedAt":"2026-08-12T00:22:02.250Z","schemaVersion":2},"datasetVersion":"2026-08-13T09:17:06.757Z"}