debug/buildinfo: module info not read when buildinfo section length exceeds 64KB

c-kruse commented 1 year ago

What version of Go are you using (`go version`)?

$ go version
go version go1.20.6 linux/amd64

Does this issue reproduce with the latest release?

Y

What operating system and processor architecture are you using (`go env`)?

linux amd64

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/christian/.cache/go-build"
GOENV="/home/christian/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/christian/go/pkg/mod"
GONOPROXY="github.com/sensu/*"
GONOSUMDB="github.com/sensu/*"
GOOS="linux"
GOPATH="/home/christian/go"
GOPRIVATE="github.com/sensu/*"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.6"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1935503120=/tmp/go-build -gno-record-gcc-switches"

What did you do?

When running go version -m on the latest release of the sumologic open telemetry collector distro.

ex:

$ wget -q https://github.com/SumoLogic/sumologic-otel-collector/releases/download/v0.81.0-sumo-0/otelcol-sumo-0.81.0-sumo-0-linux_amd64
$ go version -m otelcol-sumo-0.81.0-sumo-0-linux_amd64
otelcol-sumo-0.81.0-sumo-0-linux_amd64: go1.20.5

What did you expect to see?

I had expected to see module information as I did for the previous release. E.g.

otelcol-sumo-0.80.0-sumo-0-linux_amd64: go1.20.5
        path    github.com/SumoLogic/sumologic-otel-collector
        mod     github.com/SumoLogic/sumologic-otel-collector   (devel)
        dep     bitbucket.org/atlassian/go-asap/v2      v2.6.0  h1:KiLw3IgbzFLqNxCrVZoKUDJKMxUGoOd+NEOYXGEBhJ0=
        dep     cloud.google.com/go     v0.110.2
        =>      cloud.google.com/go     v0.110.2        h1:sdFPBr6xG9/wkBbfhmUz/JmZC7X6LavQgcrVINrKiVA=
...
        build   -buildmode=exe
        build   -compiler=gc
        build   -tags=netgo
        build   -trimpath=true
        build   CGO_ENABLED=0
        build   GOARCH=amd64
        build   GOOS=linux
        build   GOAMD64=v1
        build   vcs=git
        build   vcs.revision=727558f5fb91fd22e6a5d15f7e488b1bc7789c44
        build   vcs.time=2023-06-30T10:30:38Z
        build   vcs.modified=false

What did you see instead?

A condensed buildinfo summary with only the go build version. otelcol-sumo-0.81.0-sumo-0-linux_amd64: go1.20.5

Apparent Root Cause

Digging into the suspect binary it appears that the module info expected is embedded in the .go.buildinfo section. It looks to me like there could be an oversight here - where we read the first 64KB of the section, then give up when the encoded module info blob length exceeds the bounds.

gopherbot commented 1 year ago

Change https://go.dev/cl/514036 mentions this issue: debug/buildinfo: fix module info not read when buildinfo section length exceeds 64KB

AlexanderYastrebov commented 1 year ago

$ wc -c otelcol-sumo-0.81.0-sumo-0-linux_amd64 
186216448 otelcol-sumo-0.81.0-sumo-0-linux_amd64
$ grep -a -b -o -F 'Go buildinf:' otelcol-sumo-0.81.0-sumo-0-linux_amd64 
183476226:Go buildinf:

AlexanderYastrebov commented 1 year ago

Its unfortunate that DataStart() API does not return segment size (maybe its not known in some platforms though hard to imagine) - otherwise it could be used as a limit instead of 64k https://github.com/golang/go/blob/457721cd52008146561c80d686ce1bb18285fe99/src/debug/buildinfo/buildinfo.go#L151-L157

gopherbot commented 1 year ago

Change https://go.dev/cl/514075 mentions this issue: debug/buildinfo: read full data segment to lookup buildinfo magic

ianlancetaylor commented 1 year ago

For the record, it looks like the problem is that the .go.buildinfo section is 66144 bytes, whereas we only read 65536 bytes.

AlexanderYastrebov commented 1 year ago

For the record, it looks like the problem is that the .go.buildinfo section is 66144 bytes

yes:

$ objdump -h otelcol-sumo-0.81.0-sumo-0-linux_amd64

otelcol-sumo-0.81.0-sumo-0-linux_amd64:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         04d2f438  0000000000401000  0000000000401000  00001000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       02c242f5  0000000005131000  0000000005131000  04d31000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .typelink     00054518  0000000007d553a0  0000000007d553a0  079553a0  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .itablink     00017e88  0000000007da98c0  0000000007da98c0  079a98c0  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .gosymtab     00000000  0000000007dc1748  0000000007dc1748  079c1748  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .gopclntab    03537c68  0000000007dc1760  0000000007dc1760  079c1760  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .go.buildinfo 00010260  000000000b2fa000  000000000b2fa000  0aefa000  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  7 .noptrdata    001ebdb2  000000000b30a260  000000000b30a260  0af0a260  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  8 .data         000a08d0  000000000b4f6020  000000000b4f6020  0b0f6020  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  9 .bss          000698e0  000000000b596900  000000000b596900  0b196900  2**5
                  ALLOC
 10 .noptrbss     000163d0  000000000b6001e0  000000000b6001e0  0b2001e0  2**5
                  ALLOC
 11 .note.go.buildid 00000064  0000000000400f9c  0000000000400f9c  00000f9c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

golang / go