Skip Menu |
Report information
Id: 134076
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: jkeenan [at] pobox.com
Cc:
AdminCc:

Operating System: freebsd
PatchStatus: (no value)
Severity: low
Type: (no value)
Perl Version:
  • 5.29.8
  • 5.29.9
  • 5.29.10
Fixed In: (no value)



Subject: 009297a2 generates 'Cannot allocate memory' messages on FreeBSD-13 on unthreaded builds
From: James E Keenan <jkeenan [...] pobox.com>
To: perlbug [...] perl.org
Date: Thu, 2 May 2019 22:04:47 -0400
Download (untitled) / with headers
text/plain 3.1k
In https://rt.perl.org/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 009297a2038ba032bc4afb183cb92f738000d8ad 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' 009297a20.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 009297a20, 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
Download run-log-one-commit.sh
application/x-shellscript 562b

Message body not shown because it is not plain text.

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 3.6k
On Fri, 03 May 2019 02:04:56 GMT, jkeenan@pobox.com wrote: Show quoted text
> In https://rt.perl.org/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 009297a2038ba032bc4afb183cb92f738000d8ad > 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' > 009297a20.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 009297a20, 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)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 3.9k
On Fri, 03 May 2019 16:19:38 -0700, jkeenan wrote: Show quoted text
> On Fri, 03 May 2019 02:04:56 GMT, jkeenan@pobox.com wrote:
> > In https://rt.perl.org/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 009297a2038ba032bc4afb183cb92f738000d8ad > > 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' > > 009297a20.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 009297a20, 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
Download (untitled) / with headers
text/plain 313b
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org