Summary: | dev-util/promu-0.15.0 segfault on x86 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robin Johnson <robbat2> |
Component: | Current packages | Assignee: | Zac Medico <zmedico> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | me, williamh, zmedico |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://github.com/prometheus/promu/issues/278 | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=702598 https://github.com/gentoo/gentoo/pull/33937 https://bugs.gentoo.org/show_bug.cgi?id=924632 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Robin Johnson
2023-11-19 00:58:16 UTC
node_exporter has similar issues as well. Common pattern: built via portage -> segfault built outside portage -> works node_exporter-1.3.1 w/ goversion="go1.18.3" previously worked (known because of metrics). Tested: ------- node_exporter-1.7.0 (via Rahil's PR) node_exporter-1.5.0 node_exporter-1.4.0 X promu-0.14.0 X go 1.21.4 go 1.21.3 go 1.20.8 All segfaults. Other portage-built golang works, e.g. brand new build of goawk (which can get marked as ~x86 now, I tested it). It seems that the trouble begins when the Makefile uses promu to rebuild itself. It builds a working, dynamically linked promu first via go install, which installs it to /var/tmp/portage/dev-util/promu-0.15.0/homedir/go/bin/promu. It uses that to build the statically linked /var/tmp/portage/dev-util/promu-0.15.0/work/promu-0.15.0/promu-0.15.0 which segfaults. The promu-0.14.0 ebuild used ego build instead of the Makefile, so it is not affected by this problem. I wonder if there is some previous version that doesn't segfault when built via the Makefile. I patched the Makefile to add --cgo to the promu build options, and that resulted in a working, statically linked binary that doesn't segfault: --- a/Makefile +++ b/Makefile @@ -18,4 +18,4 @@ @echo ">> installing promu" GO111MODULE=$(GO111MODULE) GOOS= GOARCH= $(GO) install github.com/prometheus/promu @echo ">> rebuilding binaries using promu" - GO111MODULE=$(GO111MODULE) $(PROMU) build --prefix $(PREFIX) + GO111MODULE=$(GO111MODULE) $(PROMU) build --cgo --prefix $(PREFIX) I'll look into this a bit more and then open an upstream issue if I can reproduce it in a container with a different distro and toolchain. As an alternative to patching the Makefile, this is another way to enable cgo and prevent the segfault issue: --- a/.promu.yml +++ b/.promu.yml @@ -2,6 +2,7 @@ # Whenever the Go version is updated here, # .circle/config.yml should also be updated. version: 1.20 + cgo: true repository: path: github.com/prometheus/promu build: I was not able to reproduce this issue using the 386 version of the debian:unstable-20231030 docker image and debian's go1.21.4 package. It's something about GOFLAGS and/or GOMODCACHE variables (or the dependency tarball), since the problem goes away if I unset those variables. Removing -buildmode=pie from GOFLAGS like this fixed it: --- a/dev-util/promu/promu-0.15.0.ebuild +++ b/dev-util/promu/promu-0.15.0.ebuild @@ -34,6 +34,8 @@ src_unpack() { } src_compile() { + # https://bugs.gentoo.org/917577 + export GOFLAGS=${GOFLAGS//-buildmode=pie} emake build } zmedico: can we ship that patch for now on x86? Yeah, how does https://github.com/gentoo/gentoo/pull/33937 look? The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6015a94c17c9d066ba3c14380aec8cb176de7aa5 commit 6015a94c17c9d066ba3c14380aec8cb176de7aa5 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2023-11-22 16:57:39 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2023-11-25 00:59:14 +0000 dev-util/promu: Disable pie for x86 Bug: https://bugs.gentoo.org/917577 Signed-off-by: Zac Medico <zmedico@gentoo.org> dev-util/promu/promu-0.15.0.ebuild | 4 ++++ dev-util/promu/promu-9999.ebuild | 4 ++++ 2 files changed, 8 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9bd2a2d610a131178d15bc55f1c5ef2c7bd63f5f commit 9bd2a2d610a131178d15bc55f1c5ef2c7bd63f5f Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2023-11-26 21:47:01 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2023-11-26 21:47:36 +0000 app-metrics/node_exporter: workaround bug #917577 for x86 builds Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Bug: https://bugs.gentoo.org/917577 app-metrics/node_exporter/node_exporter-1.7.0.ebuild | 4 ++++ 1 file changed, 4 insertions(+) zmedico: The GOFLAGS tweak is ALSO needed on node_exporter, so I put it there. @robbat, if change is needed in per-package basis (like you made in node_exporter) then could you test other packages that uses promu? "qgrep promu" shows me alertmanager, smartctl_exporter, app-metrics/bind_exporter, app-metrics/pushgateway etc uses promu. Everything that builds a binary with "promu build" in the ebuild seems to blow up. == /var/tmp/portage/app-metrics/blackbox_exporter-0.24.0/image/usr/bin/blackbox_exporter Segmentation fault == /var/tmp/portage/app-metrics/memcached_exporter-0.10.0/image/usr/bin/memcached_exporter Segmentation fault == /var/tmp/portage/app-metrics/uwsgi_exporter-1.1.0/image/usr/bin/uwsgi_exporter Segmentation fault == /var/tmp/portage/app-metrics/bind_exporter-0.6.1/image/usr/bin/bind_exporter Segmentation fault == /var/tmp/portage/app-metrics/alertmanager-0.26.0/image/usr/bin/alertmanager Segmentation fault == /var/tmp/portage/app-metrics/alertmanager-0.26.0/image/usr/bin/amtool Segmentation fault == /var/tmp/portage/app-metrics/mysqld_exporter-0.14.0_p20230328/image/usr/bin/mysqld_exporter Segmentation fault == /var/tmp/portage/app-metrics/consul_exporter-0.7.1/image/usr/bin/consul_exporter Segmentation fault == /var/tmp/portage/app-metrics/pushgateway-1.5.1/image/usr/bin/pushgateway Segmentation fault == /var/tmp/portage/app-metrics/snmp_exporter-0.24.1/image/usr/bin/snmp_exporter Segmentation fault == /var/tmp/portage/app-metrics/prom2json-1.3.0/image/usr/bin/prom2json Segmentation fault FWIW, I found that a go build -ldflags argument as suggested in https://stackoverflow.com/questions/64019336/go-compile-to-static-binary-with-pie will result in a running pie executable on x86, though the build emits warnings that it "requires at runtime the shared libraries from the glibc version used for linking": > # go build -ldflags '-linkmode external -s -w -extldflags "--static-pie"' -buildmode=pie -tags netgo,static_build > # github.com/prometheus/promu > /usr/bin/ld: /tmp/go-link-1249323874/000002.o: in function `mygetgrouplist': > /_/GOROOT/src/os/user/getgrouplist_unix.go:15:(.text+0x29): warning: Using 'getgrouplist' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking > /usr/bin/ld: /tmp/go-link-1249323874/000001.o: in function `mygetgrgid_r': > /_/GOROOT/src/os/user/cgo_lookup_cgo.go:45:(.text+0x5d): warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking > /usr/bin/ld: /tmp/go-link-1249323874/000001.o: in function `mygetgrnam_r': > /_/GOROOT/src/os/user/cgo_lookup_cgo.go:54:(.text+0x11d): warning: Using 'getgrnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking > /usr/bin/ld: /tmp/go-link-1249323874/000001.o: in function `mygetpwnam_r': > /_/GOROOT/src/os/user/cgo_lookup_cgo.go:36:(.text+0x1e9): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking > /usr/bin/ld: /tmp/go-link-1249323874/000001.o: in function `mygetpwuid_r': > /_/GOROOT/src/os/user/cgo_lookup_cgo.go:27:(.text+0x2e9): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking > # file ./promu > ./promu: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), static-pie linked, BuildID[sha1]=4ec10f758ebc9658e18aba52616051c270a8b191, for GNU/Linux 3.2.0, stripped Repeating the same build with CGO_ENABLED=0 results in a segfaulting binary like the one that promu creates. |