Errno archname/osvers too strict.

[4kbyte]

Module: Errno

Description
The architecture check generated by ext/Errno/Errno_pm.PL at line 300 is too strict, relying on identical operating system identifiers that may have changed since Perl was installed.

The resulting file ends up at e.g. .../perl/5.36/x86_64-linux/Errno.pm

If the kernel version string changed, but the architecture and OS are otherwise consistent, the process will die on a failed comparison.

Steps to Reproduce
No simple script, but it should be reproducible by changing insignificant version information (like kernel minor version) after installing Perl, when running build scripts of Perl modules.

Two cases reported here.

Expected behavior
The check should validate on uname --kernel-name (Linux) and not uname --kernel-release (6.3.5-whatever-00013-g0c0ffee).

Perl configuration
Perl 5.36

[Leont]

That check verifies a known value against %Config. Given that both Config.pm and Errno.pm are core only, I'm puzzled how this would happen. Something must have preceded it.

[tonycoz]

I agree, the values encoded in Errno match those in Config.pm when perl is built, if they don't match then the Errno wasn't generated for the current build of perl, and Errno is correct to refuse to load.

I thought that maybe gentoo had packaged Errno separately, which could have produced this problem if perl-without-Errno had been reinstalled without installing Errno to match, but I don't see any evidence in the .ebuild file or the packages site that gentoo does that.

I had a look through the patches at https://github.com/gentoo-perl/perl-patchset/tree/perl-5.36/patches but didn't see anything that seemed like it could be the cause.

You could avoid this check by defining PERL_BUILD_EXPAND_CONFIG_VARS during perl build time, but I think you'd be ignoring the actual cause of this issue.

[thesamesam]

I don't have any immediate ideas either, although I find it a bit odd that more than one user might've hit it.

@4kbyte Did perl-cleaner --all find any ancient Perls around or similar? Or do you have any Perls in /usr/local and such?

cc @akhuettel

[4kbyte]

Thanks, all, for reviewing!

@thesamesam Only one perl install, the one shipped with gentoo. Fresh OS install, only a few weeks old, failing on package rebuild (given source distro).

Recap, in my case it was an @ in a custom kernel version string that was compared inconsistently.

(The check was saying "version-without-@" doesn't match "version-with-@" with all other version info the same.)

Reasonable to close this issue if there are no leads, and re-open if someone can make a simple reproduction. I posted here upstream because I couldn't trace anything downstream that would have affected the check.

[haarg]

The @ being part of the version clarifies the issue. The generated file includes the value of $Config{'osvers'} in a double quoted string, which means an @ will cause variable interpolation.

The value put in the generated file should have any special characters escaped to prevent this.

[tonycoz]

That resolves the instance seen by 4kbyte, it doesn't resolve the original report at https://forums.gentoo.org/viewtopic-t-1147768.html which failed with:

Errno architecture (x86_64-linux-thread-multi-5.15.0-gentoo) does not match executable architecture (x86_64-linux-thread-multi-5.8.18-gentoo) at /usr/lib64/perl5/5.34/x86_64-linux-thread-mu>

[Leont]

Sounds like the real question is "how did perl get updated but Errno.pm not?"

[thesamesam]

We don't package Errno.pm separately, so my guess would be some local install (or a dodgy package from a third-party repository).

I checked git history and it doesn't look like we've ever done it, either, but @akhuettel would know better long-term.

[akhuettel]

Does Perl check on its compilation the running kernel or the installed kernel sources?

If it checks the installed kernel sources, parallel install of a new kernel source tree and perl might mess things up. Unlikely and freak accident though...

I dont have any better idea right now. As @thesamesam says, Errno.pl is definitely not packaged separately, and to my best knowledge it never was. (Why should it?)

[tonycoz]

When configuring perl the current osvers is fetched and during the build process stored in Config.pm, this value is used later in the build process to generated Errno.pm. That same value from the installed Config.pm is compared to the value in the generated Errno.pm.

The only time the running kernel os version is checked is during configuration.

I could see this possibly happening if you:

1. configure and install perl, preserving the build tree
2. update the kernel
3. without clearing the perl build tree, configure and install perl

I don't know if the gentoo build process preserves old trees.

If this happened I'd expect problems during make test.

[Leont]

This ticket may be relevant: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343351

[thesamesam]

@tonycoz Could you reopen? The commit was 'partially fixes'. Thanks!

[jkeenan]

@tonycoz Could you reopen? The commit was 'partially fixes'. Thanks!

@thesamesam, can you describe what problems discussed in this ticket were not fixed by 8f93839? What remains to be done?

[tonycoz]

It can happen when there's a long lived process linked to libperl that attempts to load Errno after a perl upgrade, ie.

1. long-lived process starts, eg Apache with mod_perl, and loads %Config
2. perl upgraded, with modified osvers in %Config, and generated into Errno
3. long-lived process attempts to load Errno and osvers mismatches

The only fix I can see is to add a Configure option to disable the check.

[tonycoz]

Looking (again) at the Errno_pm.PL source, it looks like you can already skip this check by setting PERL_BUILD_EXPAND_CONFIG_VARS in the environment when building perl.

This also hard codes some %Config values in DynaLoader and lib.pm, which may make it unusable for you, but I think that's unlikely.

[thesamesam]

@tonycoz Could you reopen? The commit was 'partially fixes'. Thanks!

@thesamesam, can you describe what problems discussed in this ticket were not fixed by 8f93839? What remains to be done?

It's still unclear to me how the original bug could happen. Interestingly, two people reported it on our forums, and I've never heard of it before (or since). The only thing I can think of is if you.. forcefully resumed a Perl build (we do clean builds by default) with a reboot to upgrade kernel inbetween?

I don't get how the original case of different kernel version can really happen. Is the check a bit noisy in this case? Yes, but I can't really say it's definitely wrong because I can't investigate a case where it happened.

So, from my perspective, we're okay to close this until we have some reproducer. Thank you.

[tonycoz]

It's still unclear to me how the original bug could happen.

I can see how the original bug can happen if perl is upgraded eg. from 5.36.0-1 to 5.36.0-2 in Debian, a while a long lived process is running, which then attempts to load Errno.

We do appear to have a workaround that distributions can use to avoid the issue, but Debian patch out the lines of code that do the check as well as the code for the workaround rather than using the workaround: setting PERL_BUILD_EXPAND_CONFIG_VARS in the environment when building perl.

[thesamesam]

Ah, sorry, I understand you now. But that doesn't seem to have been the case for any of the Gentoo cases we had, as they were all short-lived processes just-spawned where a package build failed.

We can take a look at PERL_BUILD_EXPAND_CONFIG_VARS though. At a glance, it looks like it might be suitable for us.

[jkeenan]

This ticket now (or once again) appears to be closable. @tonycoz, anything more to do or add? Thanks.

[jkeenan]

This ticket now (or once again) appears to be closable. @tonycoz, anything more to do or add? Thanks.

@tonycoz, is it okay for us to close this ticket? Thanks.

[tonycoz]

Thanks for the reminder.

I think PERL_BUILD_EXPAND_CONFIG_VARS resolves the test, if anyone still has issues they can open a new ticket.