BBC: AYOUNG/OpenVZ-0.01.tar.gz fails since 5.31.7

[eserte]

OpenVZ-0.01 fails since perl 5.31.7. See http://fast-matrix.cpantesters.org/?dist=OpenVZ%200.01
It seems that "Out of memory" errors happen here.

Please note that the test suite always fails on *BSD systems, with all perl versions.

[jkeenan]

OpenVZ-0.01 fails since perl 5.31.7. See http://fast-matrix.cpantesters.org/?dist=OpenVZ%200.01
It seems that "Out of memory" errors happen here.

Please note that the test suite always fails on *BSD systems, with all perl versions.

Bisection point to ....

f2f32cd638746f538da6db804dab6dd54e654f30 is the first bad commit
commit f2f32cd638746f538da6db804dab6dd54e654f30
Author: David Mitchell <davem@iabyn.com>
Date:   Fri Dec 13 13:48:25 2019 +0000
Commit:     David Mitchell <davem@iabyn.com>
CommitDate: Fri Dec 13 21:38:45 2019 +0000


    avoid identical stack traces
    
    GH #15109
    
    The output of caller() (e.g. as produced by carp::Confess) produces
    multiple identical outputs when within a nested use/require. This is
    because at the time of calling the 'BEGIN { require ... }', PL_curcop is
    set to &PL_compiling, which is a fixed buffer within the interpreter,
    whose individual file and line fields are saved and restored when doing
    a new require/eval. This means that within the innermost require,
    PL_compiling has file:lineno of the innermost source file, and multiple
    saved PL_curcop values in the context stack frames all point to the same
    &PL_copmpiling.  So all levels of the stack trace appear to come from the
    innermost file.
    
    This commit fixes this (after a fashion) by, at the start of calling a
    BEGIN, making PL_curcop point to a temporary copy of PL_compiling
    instead.
    
    This is all a bit of a hack.

@iabyn Dave, can you take a look?

Thank you very much.
Jim Keenan

[jkeenan]

OpenVZ-0.01 fails since perl 5.31.7. See http://fast-matrix.cpantesters.org/?dist=OpenVZ%200.01
It seems that "Out of memory" errors happen here.
Please note that the test suite always fails on *BSD systems, with all perl versions.

Bisection point to ....

f2f32cd638746f538da6db804dab6dd54e654f30 is the first bad commit
commit f2f32cd638746f538da6db804dab6dd54e654f30
Author: David Mitchell <davem@iabyn.com>
Date:   Fri Dec 13 13:48:25 2019 +0000
Commit:     David Mitchell <davem@iabyn.com>
CommitDate: Fri Dec 13 21:38:45 2019 +0000


    avoid identical stack traces
    
    GH #15109
    
    The output of caller() (e.g. as produced by carp::Confess) produces
    multiple identical outputs when within a nested use/require. This is
    because at the time of calling the 'BEGIN { require ... }', PL_curcop is
    set to &PL_compiling, which is a fixed buffer within the interpreter,
    whose individual file and line fields are saved and restored when doing
    a new require/eval. This means that within the innermost require,
    PL_compiling has file:lineno of the innermost source file, and multiple
    saved PL_curcop values in the context stack frames all point to the same
    &PL_copmpiling.  So all levels of the stack trace appear to come from the
    innermost file.
    
    This commit fixes this (after a fashion) by, at the start of calling a
    BEGIN, making PL_curcop point to a temporary copy of PL_compiling
    instead.
    
    This is all a bit of a hack.

@iabyn Dave, can you take a look?

Bisection points to f2f32cd for test failures in Devel::Hide as well. These were reported on list:
https://www.nntp.perl.org/group/perl.perl5.porters/2020/02/msg257128.html

Thank you very much.
Jim Keenan

[iabyn]

On Mon, Feb 17, 2020 at 05:01:45AM -0800, James E Keenan wrote: > > OpenVZ-0.01 fails since perl 5.31.7. See http://fast-matrix.cpantesters.org/?dist=OpenVZ%200.01 > > It seems that "Out of memory" errors happen here. > > Please note that the test suite always fails on *BSD systems, with all perl versions. > > Bisection point to ....

[snip]

> @iabyn Dave, can you take a look?

Should be fixed now with v5.31.9-121-gfb8188b84d.

Bisection points to f2f32cd for test failures in Devel::Hide as well. These were reported on list: https://www.nntp.perl.org/group/perl.perl5.porters/2020/02/msg257128.html

Turns out that's a separate issue - I'll comment on that thread.

…

-- All wight. I will give you one more chance. This time, I want to hear no Wubens. No Weginalds. No Wudolf the wed-nosed weindeers. -- Life of Brian

[atoomic]

I had to revert the change from fb8188b which was causing some other issues during global destruction as seen on the smokers

Unbalanced string table refcount: (1) for "open_IN" during global destruction.

view https://github.com/atoomic/perl5/runs/504137544?check_suite_focus=true

[jkeenan]

OpenVZ-0.01 fails since perl 5.31.7. See http://fast-matrix.cpantesters.org/?dist=OpenVZ%200.01
It seems that "Out of memory" errors happen here.

Please note that the test suite always fails on *BSD systems, with all perl versions.

@eserte Am I correct in understanding you to say that the OpenVZ test failures on *BSD are not Perl 5-related problems, but the distribution's problems?

If so, then I think we can close this ticket, as I am now able to install OpenVZ against blead on Linux. What do your CPANtesters say?

Thank you very much.
Jim Keenan

[eserte]

It fails on *BSD since perl 5.8.9, so it's at least not a new bleadperl problem.
We'll get CPANTesters results probably with 5.31.10.

[iabyn]

On Thu, Mar 12, 2020 at 02:19:33PM -0700, Nicolas R. wrote: I had to revert the change from fb8188b which was causing some other issues during global destruction as seen on the smokers `Unbalanced string table refcount: (1) for "open_IN" during global destruction.`

Fixed fix now pushed as v5.31.9-162-gad89278aa2

…

-- I thought I was wrong once, but I was mistaken.