Since https://go.dev/cl/514075, debug/buildinfo reads the entire "data segment/section" containing the buildinfo in one go, regardless of size.
Normally, DataStart returns the .go.buildinfo section, which should be a modest size (and we'll need all of it anyway). But if the binary is stripped, or simply not a Go binary, then as a fallback it returns the first loadable data segment, which could be arbitrarily large.
This can be painful for tools scanning binaries in low-memory environments (e.g., CI), as the data segment could be quite large.
This is conceptually similar to #68454, but more straightforward to fix as this is all internal and could do chunked reading.
cc @mknyszek @zpavlinovic
Comment From: prattmic
But if the binary is stripped, or simply not a Go binary
Sorry, strip alone doesn't strip the section headers, so .go.buildinfo can still be found. strip --strip-section-headers will do so.
Comment From: gopherbot
Change https://go.dev/cl/601460 mentions this issue: debug/buildinfo: reuse buffer in searchMagic
Comment From: gopherbot
Change https://go.dev/cl/601457 mentions this issue: debug/buildinfo: add old-Go and not-Go tests
Comment From: gopherbot
Change https://go.dev/cl/601458 mentions this issue: debug/buildinfo: add test for malformed strings
Comment From: gopherbot
Change https://go.dev/cl/601456 mentions this issue: debug/buildinfo: improve format documentation
Comment From: gopherbot
Change https://go.dev/cl/601459 mentions this issue: debug/buildinfo: read data in chunks
Comment From: gopherbot
Change https://go.dev/cl/602435 mentions this issue: debug/buildid: treat too large string as "not a Go executable"