the build on this dev-lang/perl version fails on all my systems while launching miniperl which stops with the message: Attempt to free unreferenced scalar: SV 0x561970a28330 at lib/strict.pm Reproducible: Always Steps to Reproduce: 1. Try to build dev-lang/perl-5.34.1-r3 2. Wait for the sentence 3. Actual Results: Build fails Expected Results: Build should succeed I'm not used with perl, thus I don't feel like investigating about this problem. As it seems that nobody have seen this bug before, it may be due to some global system configurations like hardening (on servers), kernel random memory mapping, or anything else... Following the logs for 3 systems: S0: online server, hardened, minimal configuration with lots of security features S1: local server, hardened, with more enabled features / software than S0 other: a laptop, not hardened with a lot of software installed
Created attachment 824755 [details] Build log for the "S0" server
Created attachment 824757 [details] output from emerge --info ==dev-lang/perl-5.34.1-r3 on "S0" server
Created attachment 824759 [details] Build log for the "S1" server
Created attachment 824761 [details] Output from emerge --info =dev-lang/perl-5.34.1-r3 on "S1" server
Created attachment 824763 [details] Build log for the laptop
Created attachment 824765 [details] Output from emerge --info =dev-lang/perl-5.34.1-r3 on the laptop
Note that I did took emerge --info for a previous version for the laptop because it seems that when the package did not merge we don't have the packages settings at the end of the log
My bet is this is somehow related to bug 821577, i.e. the -fno-strict-aliasing is getting dropped somewhere. Is that enough of a hint for now for you to poke at it more? I don't have time atm unfortunately.
(In reply to Sam James from comment #8) > My bet is this is somehow related to bug 821577, i.e. the > -fno-strict-aliasing is getting dropped somewhere. > > Is that enough of a hint for now for you to poke at it more? I don't have > time atm unfortunately. You're right, it seems to be the exact same bug with the only difference as I don't get a segfault after the crash. I will try to investigate the build flags, as you suggest, thanks !
(In reply to Jocelyn Mayer from comment #9) > (In reply to Sam James from comment #8) > > My bet is this is somehow related to bug 821577, i.e. the > > -fno-strict-aliasing is getting dropped somewhere. > > > > Is that enough of a hint for now for you to poke at it more? I don't have > > time atm unfortunately. > > You're right, it seems to be the exact same bug with the only difference as > I don't get a segfault after the crash. > I will try to investigate the build flags, as you suggest, thanks ! I can confirm that the problem is due to strict aliasing issue. The '-fno-strict-aliasing' flag is not dropped by the build system but I don't enable it as global compilation flag. Forcing it to be used (using a dedicated /etc/portage/env file) made me able to build dev-lang/perl on 5 different systems with different configurations (hardened enabled / disabled, lto en / dis, ...), all amd64 based. It seems that test would failed at least for some configuration but I did not investigate this. I noticed that there still are numerous compilation warnings about potential undefinied behavior including, but not only, code like : s += SOMETHING(s); For the issue I reported, forcing fno-strict-aliasing in the ebuild seems to me to be a reasonable fix.
(In reply to Jocelyn Mayer from comment #10) > (In reply to Jocelyn Mayer from comment #9) > > (In reply to Sam James from comment #8) > > > My bet is this is somehow related to bug 821577, i.e. the > > > -fno-strict-aliasing is getting dropped somewhere. > > > > > > Is that enough of a hint for now for you to poke at it more? I don't have > > > time atm unfortunately. > > > > You're right, it seems to be the exact same bug with the only difference as > > I don't get a segfault after the crash. > > I will try to investigate the build flags, as you suggest, thanks ! > > I can confirm that the problem is due to strict aliasing issue. > The '-fno-strict-aliasing' flag is not dropped by the build system but I > don't enable it as global compilation flag. The weird thing is it's enabled by -O2. I was suspicious that perhaps your(?) "-Wstrict-aliasing" was confusing the (very weird) Perl build system (maybe it greps for "strict-aliasing" and then skips addint -fno-strict-aliasing if present). > Forcing it to be used (using a dedicated /etc/portage/env file) made me able > to build dev-lang/perl on 5 different systems with different configurations > (hardened enabled / disabled, lto en / dis, ...), all amd64 based. It seems > that test would failed at least for some configuration but I did not > investigate this. Fantastic! Yeah, it's obviously failing for some weird reason. > I noticed that there still are numerous compilation warnings about potential > undefinied behavior including, but not only, code like : s += SOMETHING(s); > > For the issue I reported, forcing fno-strict-aliasing in the ebuild seems to > me to be a reasonable fix. Given this is the second time it's come up, I agree, let's just bung it in append-flags.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=28d674673b7e0198d2770ec5a780966555dbbc6a commit 28d674673b7e0198d2770ec5a780966555dbbc6a Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-28 12:36:37 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-28 12:37:31 +0000 dev-lang/perl: always pass -fno-strict-aliasing We keep getting these bugs where it turns out the build system didn't pass it for us, so just unconditionally do it. Closes: https://bugs.gentoo.org/877659 Signed-off-by: Sam James <sam@gentoo.org> dev-lang/perl/{perl-5.34.1-r3.ebuild => perl-5.34.1-r4.ebuild} | 5 ++++- dev-lang/perl/{perl-5.36.0.ebuild => perl-5.36.0-r1.ebuild} | 5 ++++- 2 files changed, 8 insertions(+), 2 deletions(-)
