From @jkeenan

In https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133958 we have been
studying intermittent test failures in cpan/Test-Simple/t/Legacy/More.t
in unthreaded builds on FreeBSD-13. In the course of this discussion we
have also reported that in those builds certain items in the test suite
PASS but then are followed by a message​:

#####
Cannot allocate memory
#####

We do not have a target for Porting/bisect.pl by which we can capture
the entire output of 'make test_harness' re-direct it to a file and then
run a test on that file that can give a Boolean result which can be used
during bisection to indicate whether we need to go forward or back in
the commit list to identify the commit where a problem first became
manifest. Hence, I had to bisect manually, i.e., by checking out
commits and running them one at a time to detect the key phrase. I
checked out tags until I got to the range from v5.29.7 to v5.29.8, then
ran this command​:

#####
git rev-list --reverse v5.29.7..v5.29.8 > 52907-to-52908-commits.txt
#####

... to get a list of commits over which to bisect. Eventually I
realized that, once I had identified an unsatisfactory commit, I did not
have to run all of 'make test_harness' to get data. I could meaningful
data just by running the tests in the t/io/ and t/re/ subdirectories
with the attached script run-log-one-commit.sh.

Bisection pointed to this commit​:

#####
commit 009297a
Author​: Karl Williamson <khw@​cpan.org>
AuthorDate​: Mon Feb 4 15​:23​:31 2019 -0700
Commit​: Karl Williamson <khw@​cpan.org>
CommitDate​: Tue Feb 5 11​:44​:29 2019 -0700

t/re/fold_grind.pl​: Enhance to deal with Turkic rules

The CaseFolding.txt file has special locale-dependent
rules. This commit changed fold_grind to notice them, and
to generate tests for the situation we aren't in, which are
expected to fail.

Since, as of this commit, the Turkic locale is not
recognized, this commit has the effect of generating tests
for the Turkic locale, running them, and making sure they
fail when appropriate.
#####

At this commit, the following 6 test files were followed by the errant
message.

#####
$ zgrep -B1 'Cannot allocate memory'
009297a.unthreaded.full.make.test_harness.log.gz
re/anyof.t ......................................................... ok
Cannot allocate memory
re/fold_grind_8.t .................................................. ok
Cannot allocate memory
re/fold_grind_a.t .................................................. ok
Cannot allocate memory
re/fold_grind_d.t .................................................. ok
Cannot allocate memory
re/fold_grind_aa.t ................................................. ok
Cannot allocate memory
--
re/reg_eval_scope.t ................................................ ok
Cannot allocate memory
#####

Now, when I ran a full 'make test_harness' at 009297a, I did *not* get
a failure in cpan/Test-Simple/t/Legacy/More.t. However, that didn't
surprise me, as those failures have always been intermittent. But one
path of investigation might be to get these 'Cannot allocate memory'
messages and see fi that clears up the More.t problem

Thank you very much.
Jim Keenan

From @jkeenan

run-log-one-commit.sh

From @jkeenan

Summary of my perl5 (revision 5 version 29 subversion 8) configuration​:
  Commit id​: 009297a
  Platform​:
  osname=freebsd
  osvers=13.0-current
  archname=amd64-freebsd
  uname='freebsd freebsd 13.0-current freebsd 13.0-current r340361 generic amd64 '
  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 ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2'
  optimize='-O2'
  cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
  ccversion=''
  gccversion='4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)'
  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 ='-Wl,-E -fstack-protector-strong -L/usr/local/lib'
  libpth=/usr/lib /usr/local/lib /usr/lib/clang/6.0.1/lib /usr/lib
  libs=-lpthread -lgdbm -ldl -lm -lcrypt -lutil -lc
  perllibs=-lpthread -ldl -lm -lcrypt -lutil -lc
  libc=
  so=so
  useshrplib=false
  libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs
  dlext=so
  d_dlsymun=undef
  ccdlflags=' '
  cccdlflags='-DPIC -fPIC'
  lddlflags='-shared -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 freebsd
  Compiled at May 2 2019 21​:24​:02
  %ENV​:
  PERL2DIR="/home/jkeenan/gitwork/perl2"
  PERL_WORKDIR="/home/jkeenan/gitwork/perl"
  @​INC​:
  lib
  /usr/local/lib/perl5/site_perl/5.29.8/amd64-freebsd
  /usr/local/lib/perl5/site_perl/5.29.8
  /usr/local/lib/perl5/5.29.8/amd64-freebsd
  /usr/local/lib/perl5/5.29.8

From @jkeenan

On Fri, 03 May 2019 02​:04​:56 GMT, jkeenan@​pobox.com wrote​:

In https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133958 we have been
studying intermittent test failures in cpan/Test-Simple/t/Legacy/More.t
in unthreaded builds on FreeBSD-13. In the course of this discussion we
have also reported that in those builds certain items in the test suite
PASS but then are followed by a message​:

#####
Cannot allocate memory
#####

We do not have a target for Porting/bisect.pl by which we can capture
the entire output of 'make test_harness' re-direct it to a file and then
run a test on that file that can give a Boolean result which can be used
during bisection to indicate whether we need to go forward or back in
the commit list to identify the commit where a problem first became
manifest. Hence, I had to bisect manually, i.e., by checking out
commits and running them one at a time to detect the key phrase. I
checked out tags until I got to the range from v5.29.7 to v5.29.8, then
ran this command​:

#####
git rev-list --reverse v5.29.7..v5.29.8 > 52907-to-52908-commits.txt
#####

... to get a list of commits over which to bisect. Eventually I
realized that, once I had identified an unsatisfactory commit, I did not
have to run all of 'make test_harness' to get data. I could meaningful
data just by running the tests in the t/io/ and t/re/ subdirectories
with the attached script run-log-one-commit.sh.

Bisection pointed to this commit​:

#####
commit 009297a
Author​: Karl Williamson <khw@​cpan.org>
AuthorDate​: Mon Feb 4 15​:23​:31 2019 -0700
Commit​: Karl Williamson <khw@​cpan.org>
CommitDate​: Tue Feb 5 11​:44​:29 2019 -0700

t/re/fold_grind.pl​: Enhance to deal with Turkic rules

The CaseFolding.txt file has special locale-dependent
rules. This commit changed fold_grind to notice them, and
to generate tests for the situation we aren't in, which are
expected to fail.

Since, as of this commit, the Turkic locale is not
recognized, this commit has the effect of generating tests
for the Turkic locale, running them, and making sure they
fail when appropriate.
#####

At this commit, the following 6 test files were followed by the errant
message.

#####
$ zgrep -B1 'Cannot allocate memory'
009297a.unthreaded.full.make.test_harness.log.gz
re/anyof.t ......................................................... ok
Cannot allocate memory
re/fold_grind_8.t .................................................. ok
Cannot allocate memory
re/fold_grind_a.t .................................................. ok
Cannot allocate memory
re/fold_grind_d.t .................................................. ok
Cannot allocate memory
re/fold_grind_aa.t ................................................. ok
Cannot allocate memory
--
re/reg_eval_scope.t ................................................ ok
Cannot allocate memory
#####

Now, when I ran a full 'make test_harness' at 009297a, I did *not* get
a failure in cpan/Test-Simple/t/Legacy/More.t. However, that didn't
surprise me, as those failures have always been intermittent. But one
path of investigation might be to get these 'Cannot allocate memory'
messages and see fi that clears up the More.t problem

Thank you very much.
Jim Keenan

Tony Cook's smoke-me/tonyc/133958-realloc-errno-success branch appears to have cleared up these 'Cannot allocate memory' messages. Once I get another good smoke-test report for this branch from our other FreeBSD-13 smoker, I would like (permission) to have this merged into blead.

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

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

From @tonycoz

On Fri, 03 May 2019 16​:19​:38 -0700, jkeenan wrote​:

On Fri, 03 May 2019 02​:04​:56 GMT, jkeenan@​pobox.com wrote​:

In https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133958 we have been
studying intermittent test failures in cpan/Test-
Simple/t/Legacy/More.t
in unthreaded builds on FreeBSD-13. In the course of this discussion
we
have also reported that in those builds certain items in the test
suite
PASS but then are followed by a message​:

#####
Cannot allocate memory
#####

We do not have a target for Porting/bisect.pl by which we can capture
the entire output of 'make test_harness' re-direct it to a file and
then
run a test on that file that can give a Boolean result which can be
used
during bisection to indicate whether we need to go forward or back in
the commit list to identify the commit where a problem first became
manifest. Hence, I had to bisect manually, i.e., by checking out
commits and running them one at a time to detect the key phrase. I
checked out tags until I got to the range from v5.29.7 to v5.29.8,
then
ran this command​:

#####
git rev-list --reverse v5.29.7..v5.29.8 > 52907-to-52908-commits.txt
#####

... to get a list of commits over which to bisect. Eventually I
realized that, once I had identified an unsatisfactory commit, I did
not
have to run all of 'make test_harness' to get data. I could
meaningful
data just by running the tests in the t/io/ and t/re/ subdirectories
with the attached script run-log-one-commit.sh.

Bisection pointed to this commit​:

#####
commit 009297a
Author​: Karl Williamson <khw@​cpan.org>
AuthorDate​: Mon Feb 4 15​:23​:31 2019 -0700
Commit​: Karl Williamson <khw@​cpan.org>
CommitDate​: Tue Feb 5 11​:44​:29 2019 -0700

t/re/fold_grind.pl​: Enhance to deal with Turkic rules

The CaseFolding.txt file has special locale-dependent
rules. This commit changed fold_grind to notice them, and
to generate tests for the situation we aren't in, which are
expected to fail.

Since, as of this commit, the Turkic locale is not
recognized, this commit has the effect of generating tests
for the Turkic locale, running them, and making sure they
fail when appropriate.
#####

At this commit, the following 6 test files were followed by the
errant
message.

#####
$ zgrep -B1 'Cannot allocate memory'
009297a.unthreaded.full.make.test_harness.log.gz
re/anyof.t .........................................................
ok
Cannot allocate memory
re/fold_grind_8.t ..................................................
ok
Cannot allocate memory
re/fold_grind_a.t ..................................................
ok
Cannot allocate memory
re/fold_grind_d.t ..................................................
ok
Cannot allocate memory
re/fold_grind_aa.t .................................................
ok
Cannot allocate memory
--
re/reg_eval_scope.t ................................................
ok
Cannot allocate memory
#####

Now, when I ran a full 'make test_harness' at 009297a, I did *not*
get
a failure in cpan/Test-Simple/t/Legacy/More.t. However, that didn't
surprise me, as those failures have always been intermittent. But
one
path of investigation might be to get these 'Cannot allocate memory'
messages and see fi that clears up the More.t problem

Thank you very much.
Jim Keenan

Tony Cook's smoke-me/tonyc/133958-realloc-errno-success branch appears
to have cleared up these 'Cannot allocate memory' messages. Once I
get another good smoke-test report for this branch from our other
FreeBSD-13 smoker, I would like (permission) to have this merged into
blead.

Thank you very much.

It's been merged, marking this pending release.

Tony

@tonycoz - Status changed from 'open' to 'pending release'

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release today of Perl 5.30.0, this and 160 other issues have been
resolved.

Perl 5.30.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.30.0

If you find that the problem persists, feel free to reopen this ticket.

@khwilliamson - Status changed from 'pending release' to 'resolved'