Skip to content
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

Threaded builds failing on Fedora 28 #16552

Closed
p5pRT opened this issue May 7, 2018 · 13 comments
Closed

Threaded builds failing on Fedora 28 #16552

p5pRT opened this issue May 7, 2018 · 13 comments

Comments

@p5pRT
Copy link

p5pRT commented May 7, 2018

Migrated from rt.perl.org#133184 (status was 'open')

Searchable as RT133184$

@p5pRT
Copy link
Author

p5pRT commented May 7, 2018

From @jkeenan

Threaded builds of Perl 5 blead are failing, apparently during miniperl,
on very recent Linux kernels. See any of the smoke tests generated by
Carlos Guevara on linux - 4.16.5 or higher, e.g.,
http​://perl5.test-smoke.org/report/65701. In that report, this
configuration was tested​:

#####
Automated smoke report for branch blead 5.28.0 patch
38c84d6 v5.27.11-30-g38c84d6ad1
cjg-fedora28​: Intel(R) Xeon(R) CPU E5420 @​ 2.50GHz (GenuineIntel
2500MHz) (x86_64/1 cpus)
  on linux 4.16.5-300.fc28.x86_64 [Fedora 28 (Server Edition)]
  using cc version 8.0.1 20180324 (Red Hat 8.0.1-0.20)
#####

... which ultimately fails with​:

#####
pp.c​: In function 'Perl_pp_crypt'​:
  pp.c​:3657​:47​: error​: 'struct crypt_data' has no member named
'current_saltbits'

#####

Here's some dialog from #p5p about this problem​:

#####
(05​:16​:06 PM) khw​: Is anyone working on the blead failures with the new
Linux?
(05​:16​:08 PM) khw​: pp.c​: In function 'Perl_pp_crypt'​:
(05​:16​:09 PM) khw​: pp.c​:3657​:47​: error​: 'struct crypt_data' has no
member named 'current_saltbits'
...
(06​:11​:30 PM) xenu​: khw​: nginx had exactly the same problem
https://trac.nginx.org/nginx/ticket/1469
(06​:12​:04 PM) xenu​: imo that code should be removed, it's a workaround
for bug in glibc from 2002
...
(06​:20​:26 PM) khw​: right. 4.16
(06​:20​:36 PM) khw​: which I presumed was new
(06​:23​:20 PM) xenu​: also, that bug is specific to fedora
...
(06​:29​:06 PM) xenu​: i think that no one noticed that before because
fedora 28 was released just a week ago
(06​:32​:17 PM) xenu​:
https://src.fedoraproject.org/cgit/rpms/perl.git/tree/perl-5.26.1-guard_old_libcrypt_fix.patch
(06​:32​:56 PM) xenu​: that's the patch fedora is using to fix the problem
(06​:33​:43 PM) xenu​: (imo it's too defensive, i really don't think
there's a valid reason to keep supporting ancient glibc versions)
(06​:39​:13 PM) ***khw wonders if 5.28 will be released before YAPC
#####

@p5pRT
Copy link
Author

p5pRT commented May 7, 2018

From @jkeenan

Summary of my perl5 (revision 5 version 27 subversion 10) configuration​:
  Commit id​: f0282de
  Platform​:
  osname=linux
  osvers=4.4.0-112-generic
  archname=x86_64-linux
  uname='linux zareason 4.4.0-112-generic #135-ubuntu smp fri jan 19 11​:48​:36 utc 2018 x86_64 x86_64 x86_64 gnulinux '
  config_args='-des -Dusedevel'
  hint=recommended
  useposix=true
  d_sigaction=define
  useithreads=undef
  usemultiplicity=undef
  use64bitint=define
  use64bitall=define
  uselongdouble=undef
  usemymalloc=n
  default_inc_excludes_dot=define
  bincompat5005=undef
  Compiler​:
  cc='cc'
  ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
  optimize='-O2'
  cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
  ccversion=''
  gccversion='5.4.1 20160904'
  gccosandvers=''
  intsize=4
  longsize=8
  ptrsize=8
  doublesize=8
  byteorder=12345678
  doublekind=3
  d_longlong=define
  longlongsize=8
  d_longdbl=define
  longdblsize=16
  longdblkind=3
  ivtype='long'
  ivsize=8
  nvtype='double'
  nvsize=8
  Off_t='off_t'
  lseeksize=8
  alignbytes=8
  prototype=define
  Linker and Libraries​:
  ld='cc'
  ldflags =' -fstack-protector-strong -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /lib64 /usr/lib64
  libs=-lpthread -lnsl -ldb -ldl -lm -lcrypt -lutil -lc
  perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.23.so
  so=so
  useshrplib=false
  libperl=libperl.a
  gnulibc_version='2.23'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs
  dlext=so
  d_dlsymun=undef
  ccdlflags='-Wl,-E'
  cccdlflags='-fPIC'
  lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong'

Characteristics of this binary (from libperl)​:
  Compile-time options​:
  HAS_TIMES
  PERLIO_LAYERS
  PERL_COPY_ON_WRITE
  PERL_DONT_CREATE_GVSV
  PERL_MALLOC_WRAP
  PERL_OP_PARENT
  PERL_PRESERVE_IVUV
  PERL_USE_DEVEL
  USE_64_BIT_ALL
  USE_64_BIT_INT
  USE_LARGE_FILES
  USE_LOCALE
  USE_LOCALE_COLLATE
  USE_LOCALE_CTYPE
  USE_LOCALE_NUMERIC
  USE_LOCALE_TIME
  USE_PERLIO
  USE_PERL_ATOF
  Built under linux
  Compiled at Mar 20 2018 17​:28​:52
  %ENV​:
  PERL2DIR="/home/jkeenan/gitwork/perl2"
  PERLBREW_BASHRC_VERSION="0.78"
  PERLBREW_HOME="/home/jkeenan/.perlbrew"
  PERLBREW_MANPATH="/home/jkeenan/perl5/perlbrew/perls/perl-5.26.0/man"
  PERLBREW_PATH="/home/jkeenan/perl5/perlbrew/bin​:/home/jkeenan/perl5/perlbrew/perls/perl-5.26.0/bin"
  PERLBREW_PERL="perl-5.26.0"
  PERLBREW_ROOT="/home/jkeenan/perl5/perlbrew"
  PERLBREW_VERSION="0.78"
  PERL_WORKDIR="/home/jkeenan/gitwork/perl"
  @​INC​:
  lib
  /usr/local/lib/perl5/site_perl/5.27.10/x86_64-linux
  /usr/local/lib/perl5/site_perl/5.27.10
  /usr/local/lib/perl5/5.27.10/x86_64-linux
  /usr/local/lib/perl5/5.27.10

@p5pRT
Copy link
Author

p5pRT commented May 8, 2018

From @jkeenan

On Mon, 07 May 2018 23​:08​:34 GMT, jkeenan@​pobox.com wrote​:

Threaded builds of Perl 5 blead are failing, apparently during
miniperl,
on very recent Linux kernels. See any of the smoke tests generated by
Carlos Guevara on linux - 4.16.5 or higher, e.g.,
http​://perl5.test-smoke.org/report/65701. In that report, this
configuration was tested​:

#####
Automated smoke report for branch blead 5.28.0 patch
38c84d6 v5.27.11-30-g38c84d6ad1
cjg-fedora28​: Intel(R) Xeon(R) CPU E5420 @​ 2.50GHz (GenuineIntel
2500MHz) (x86_64/1 cpus)
on linux 4.16.5-300.fc28.x86_64 [Fedora 28 (Server
Edition)]
using cc version 8.0.1 20180324 (Red Hat 8.0.1-0.20)
#####

... which ultimately fails with​:

#####
pp.c​: In function 'Perl_pp_crypt'​:
pp.c​:3657​:47​: error​: 'struct crypt_data' has no member named
'current_saltbits'

#####

Here's some dialog from #p5p about this problem​:

#####
(05​:16​:06 PM) khw​: Is anyone working on the blead failures with the
new
Linux?
(05​:16​:08 PM) khw​: pp.c​: In function 'Perl_pp_crypt'​:
(05​:16​:09 PM) khw​: pp.c​:3657​:47​: error​: 'struct crypt_data' has no
member named 'current_saltbits'
...
(06​:11​:30 PM) xenu​: khw​: nginx had exactly the same problem
https://trac.nginx.org/nginx/ticket/1469
(06​:12​:04 PM) xenu​: imo that code should be removed, it's a workaround
for bug in glibc from 2002
...
(06​:20​:26 PM) khw​: right. 4.16
(06​:20​:36 PM) khw​: which I presumed was new
(06​:23​:20 PM) xenu​: also, that bug is specific to fedora
...
(06​:29​:06 PM) xenu​: i think that no one noticed that before because
fedora 28 was released just a week ago
(06​:32​:17 PM) xenu​:
https://src.fedoraproject.org/cgit/rpms/perl.git/tree/perl-5.26.1-
guard_old_libcrypt_fix.patch
(06​:32​:56 PM) xenu​: that's the patch fedora is using to fix the
problem
(06​:33​:43 PM) xenu​: (imo it's too defensive, i really don't think
there's a valid reason to keep supporting ancient glibc versions)
(06​:39​:13 PM) ***khw wonders if 5.28 will be released before YAPC
#####

For discussion purposes, I have applied the Fedora patch indicated by xenu to the following smoke-test branch​:

smoke-me/jkeenan/133184-crypt-data

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented May 8, 2018

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented May 8, 2018

From @iabyn

On Mon, May 07, 2018 at 04​:08​:34PM -0700, James E Keenan (via RT) wrote​:

(06​:32​:56 PM) xenu​: that's the patch fedora is using to fix the problem
(06​:33​:43 PM) xenu​: (imo it's too defensive, i really don't think
there's a valid reason to keep supporting ancient glibc versions)

It's probably overly defensive, but erring on the side of safety
during code freeze is probably a good thing.

I propose we use the fedora glibc version-based patch for 5.28,
then remove the line altogether post 5.28.

--
Never do today what you can put off till tomorrow.

@p5pRT
Copy link
Author

p5pRT commented May 8, 2018

From @doughera88

On Tue, May 08, 2018 at 08​:43​:25AM +0100, Dave Mitchell wrote​:

On Mon, May 07, 2018 at 04​:08​:34PM -0700, James E Keenan (via RT) wrote​:

(06​:32​:56 PM) xenu​: that's the patch fedora is using to fix the problem
(06​:33​:43 PM) xenu​: (imo it's too defensive, i really don't think
there's a valid reason to keep supporting ancient glibc versions)

It's probably overly defensive, but erring on the side of safety
during code freeze is probably a good thing.

I didn't know the specific versions at play, but this patch is what I was
about to suggest.

I propose we use the fedora glibc version-based patch for 5.28,
then remove the line altogether post 5.28.

Yes, I agree.

--
  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented May 9, 2018

From @ppisar

On 2018-05-07, "James E Keenan (via RT)" <perlbug-followup@​perl.org> wrote​:

Threaded builds of Perl 5 blead are failing, apparently during miniperl,
on very recent Linux kernels.

That's not casued by the Linux kernel.

 on        linux 4\.16\.5\-300\.fc28\.x86\_64 \[Fedora 28 \(Server Edition\)\]

But by Fedora 18's glibc that replaced upstream's libcrypt library with
a new libxcrypt implementation. libxcrypt is not bug compatible.

https://src.fedoraproject.org/cgit/rpms/perl.git/tree/perl-5.26.1-guard_old_libcrypt_fix.patch

I tried to send this patch to p5p at least four times via e-mail, but
none of the my attempts were successfull. These days sysadmins do their
best not to deliver e-mails. Then I forgot on the patch.

(06​:32​:56 PM) xenu​: that's the patch fedora is using to fix the problem
(06​:33​:43 PM) xenu​: (imo it's too defensive, i really don't think
there's a valid reason to keep supporting ancient glibc versions)
(06​:39​:13 PM) ***khw wonders if 5.28 will be released before YAPC
#####

glibc 2.2 and 2.3 contain the bug. 2.4 was released on 2006-03-06.
Provided Perl still supports pre-ISO-C99 compilers, I worry it's too
early for removing the workaround.

-- Petr

@p5pRT
Copy link
Author

p5pRT commented May 9, 2018

From @xsawyerx

On 05/08/2018 03​:17 PM, Andy Dougherty wrote​:

On Tue, May 08, 2018 at 08​:43​:25AM +0100, Dave Mitchell wrote​:

On Mon, May 07, 2018 at 04​:08​:34PM -0700, James E Keenan (via RT) wrote​:

(06​:32​:56 PM) xenu​: that's the patch fedora is using to fix the problem
(06​:33​:43 PM) xenu​: (imo it's too defensive, i really don't think
there's a valid reason to keep supporting ancient glibc versions)
It's probably overly defensive, but erring on the side of safety
during code freeze is probably a good thing.
I didn't know the specific versions at play, but this patch is what I was
about to suggest.

I propose we use the fedora glibc version-based patch for 5.28,
then remove the line altogether post 5.28.
Yes, I agree.

Sounds good to me.

@p5pRT
Copy link
Author

p5pRT commented May 9, 2018

From @xsawyerx

Hi Petr,

Let's take this offline with Robert to see if we can figure out any
possible patch submission issues.

If anyone experiences anything like this, please let me know.
Thanks!

On 05/09/2018 03​:45 PM, Petr Pisar wrote​:

On 2018-05-07, "James E Keenan (via RT)" <perlbug-followup@​perl.org> wrote​:

Threaded builds of Perl 5 blead are failing, apparently during miniperl,
on very recent Linux kernels.
That's not casued by the Linux kernel.

 on        linux 4\.16\.5\-300\.fc28\.x86\_64 \[Fedora 28 \(Server Edition\)\]

But by Fedora 18's glibc that replaced upstream's libcrypt library with
a new libxcrypt implementation. libxcrypt is not bug compatible.

https://src.fedoraproject.org/cgit/rpms/perl.git/tree/perl-5.26.1-guard_old_libcrypt_fix.patch
I tried to send this patch to p5p at least four times via e-mail, but
none of the my attempts were successfull. These days sysadmins do their
best not to deliver e-mails. Then I forgot on the patch.

(06​:32​:56 PM) xenu​: that's the patch fedora is using to fix the problem
(06​:33​:43 PM) xenu​: (imo it's too defensive, i really don't think
there's a valid reason to keep supporting ancient glibc versions)
(06​:39​:13 PM) ***khw wonders if 5.28 will be released before YAPC
#####

glibc 2.2 and 2.3 contain the bug. 2.4 was released on 2006-03-06.
Provided Perl still supports pre-ISO-C99 compilers, I worry it's too
early for removing the workaround.

-- Petr

@p5pRT
Copy link
Author

p5pRT commented May 10, 2018

From @xenu

On 9 May 2018 12​:45​:25 -0000
Petr Pisar <ppisar@​redhat.com> wrote​:

glibc 2.2 and 2.3 contain the bug. 2.4 was released on 2006-03-06.
Provided Perl still supports pre-ISO-C99 compilers, I worry it's too
early for removing the workaround.

-- Petr

I see no connection between targeting C89 compilers and supporting
ancient Linux distributions.

@p5pRT
Copy link
Author

p5pRT commented May 11, 2018

From @iabyn

On Wed, May 09, 2018 at 10​:21​:38PM +0300, Sawyer X wrote​:

I propose we use the fedora glibc version-based patch for 5.28,
then remove the line altogether post 5.28.
Yes, I agree.

Sounds good to me.

Fedora fix now applied with v5.27.11-33-ge9c9cf5759.

I'll remove this ticket from the 5.28 blockers now.

(I've also changed the ticket's title again - its Fedora 28 rather than
18 which is failing)

--
"Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit."
  -- Lady Croom, "Arcadia"

@jkeenan
Copy link
Contributor

jkeenan commented Feb 1, 2020

In May 2018 we applied e9c9cf5 patching pp.c in response to build-time failures on Fedora 28. Is there anything we still need to do in this ticket?

Thank you very much.
Jim Keenan

@jkeenan jkeenan added the Closable? We might be able to close this ticket, but we need to check with the reporter label Feb 1, 2020
iabyn added a commit that referenced this issue Feb 3, 2020
GH #16552

In 2003 a fix was added to workaround a bug in glibc's crypt_r()
implementation (which involved tweaking a private undocumented field
within the crypt_data struct). This bug has long since been fixed, but
the workaround remained. This commit finally removes that workaround.

See also v5.27.11-33-ge9c9cf5759.
@iabyn
Copy link
Contributor

iabyn commented Feb 3, 2020 via email

@iabyn iabyn closed this as completed Feb 3, 2020
@jkeenan jkeenan removed the Closable? We might be able to close this ticket, but we need to check with the reporter label Feb 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants