New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
debug/buildinfo: module info not read when buildinfo section length exceeds 64KB #61644
Comments
Change https://go.dev/cl/514036 mentions this issue: |
|
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 go/src/debug/buildinfo/buildinfo.go Lines 151 to 157 in 457721c
|
Change https://go.dev/cl/514075 mentions this issue: |
For the record, it looks like the problem is that the |
Also fix boundary check in decodeString. Fixes golang#61644
yes:
|
Removes the broken debugging step in the build and release CI workflows showing the included collector components and their go module versions. This information is baked into the executable. To see components run the components command `otelcol-sumo components`. If more subtle debugging is required and knowing the module versions is helpful, there is a workaround until go1.22 is available with the fix for `go version -m` (golang/go#61644). Inspect the binary in a platform specific way. e.g. `objcopy -O binary -j .go.buildinfo otelcol-sumo-0.80.0-sumo-0-linux_amd64 buildinfo.txt` Signed-off-by: Christian Kruse <ctkruse99@gmail.com>
Removes the broken debugging step in the build and release CI workflows showing the included collector components and their go module versions. This information is baked into the executable. To see components run the components command `otelcol-sumo components`. If more subtle debugging is required and knowing the module versions is helpful, there is a workaround until go1.22 is available with the fix for `go version -m` (golang/go#61644). Inspect the binary in a platform specific way. e.g. `objcopy -O binary -j .go.buildinfo otelcol-sumo-0.80.0-sumo-0-linux_amd64 buildinfo.txt` Signed-off-by: Christian Kruse <ctkruse99@gmail.com>
Removes the broken debugging step in the build and release CI workflows showing the included collector components and their go module versions. This information is baked into the executable. To see components run the components command `otelcol-sumo components`. If more subtle debugging is required and knowing the module versions is helpful, there is a workaround until go1.22 is available with the fix for `go version -m` (golang/go#61644). Inspect the binary in a platform specific way. e.g. `objcopy -O binary -j .go.buildinfo otelcol-sumo-0.80.0-sumo-0-linux_amd64 buildinfo.txt` Signed-off-by: Christian Kruse <ctkruse99@gmail.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Y
What operating system and processor architecture are you using (
go env
)?linux amd64
go env
OutputWhat did you do?
When running
go version -m
on the latest release of the sumologic open telemetry collector distro.ex:
What did you expect to see?
I had expected to see module information as I did for the previous release. E.g.
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.The text was updated successfully, but these errors were encountered: