Bleadperl v5.31.9-162-gad89278aa2 breaks RIBASUSHI/DBIx-Class-0.082841.tar.gz

[andk]

As per subject. Also affected: SDPRICE/App-Framework-Lite-1.09.tar.gz, LGODDARD/CGI-ProgressBar-0.05.tar.gz

Matrix:

• http://matrix.cpantesters.org/?dist=DBIx-Class+0.082841
• http://matrix.cpantesters.org/?dist=CGI-ProgressBar+0.05
• http://matrix.cpantesters.org/?dist=App-Framework-Lite+1.09

Sample fail reports:

• http://www.cpantesters.org/cpan/report/b24aea66-69c0-11ea-a976-a84dd8968159
• http://www.cpantesters.org/cpan/report/bd8bbf48-6a1c-11ea-ab1e-1e541caaa6e3
• http://www.cpantesters.org/cpan/report/89d15860-6aae-11ea-9523-6c492daaa6e3

Regards,

[jkeenan]

This is the failure I get on blead on Linux:

$ bleadperl -v
This is perl 5, version 31, subversion 10 (v5.31.10 (v5.31.9-123-g8200912a00)) built for x86_64-linux
$ bleadprove -vb t/53lean_startup.t
t/53lean_startup.t .. 
#
not ok 1 - Unexpected require of 'MRO::Compat' by DBIx::Class::Componentised (/home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Componentised.pm line 7)

#   Failed test 'Unexpected require of 'MRO::Compat' by DBIx::Class::Componentised (/home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Componentised.pm line 7)'
#   at t/53lean_startup.t line 54.
# Require invoked at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/site_perl/5.31.10/Class/C3/Componentised.pm line 44
#   invoked as Class::C3::Componentised::BEGIN at /home/jkeenan/testing/blead/lib/perl5/site_perl/5.31.10/Class/C3/Componentised.pm line 44
#   invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/site_perl/5.31.10/Class/C3/Componentised.pm line 44
#   invoked as (eval) at (eval 1244) line 5
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 1243) line 4
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#   invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 137
#   invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 105
#   invoked as base::import at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Componentised.pm line 7
#   invoked as DBIx::Class::Componentised::BEGIN at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Componentised.pm line 7
#   invoked as (eval) at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Componentised.pm line 7
#   invoked as (eval) at (eval 1236) line 5
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 1235) line 4
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#   invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 137
#   invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 105
#   invoked as base::import at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class.pm line 23
#   invoked as DBIx::Class::BEGIN at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class.pm line 23
#   invoked as (eval) at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class.pm line 23
#   invoked as (eval) at (eval 1216) line 5
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 1215) line 4
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#   invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 137
#   invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 105
#   invoked as base::import at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Schema.pm line 6
#   invoked as DBIx::Class::Schema::BEGIN at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Schema.pm line 6
#   invoked as (eval) at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Schema.pm line 6
#   invoked as (eval) at (eval 1208) line 5
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 1207) line 4
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#   invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 137
#   invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 105
#   invoked as base::import at t/lib/DBICTest/BaseSchema.pm line 6
#   invoked as DBICTest::BaseSchema::BEGIN at t/lib/DBICTest/BaseSchema.pm line 6
#   invoked as (eval) at t/lib/DBICTest/BaseSchema.pm line 6
#   invoked as (eval) at (eval 713) line 5
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 712) line 4
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#   invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 137
#   invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 105
#   invoked as base::import at t/lib/DBICTest/Schema.pm line 8
#   invoked as DBICTest::Schema::BEGIN at t/lib/DBICTest/Schema.pm line 8
#   invoked as (eval) at t/lib/DBICTest/Schema.pm line 8
#   invoked as (eval) at (eval 703) line 5
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 702) line 4
#   invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#   invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#   invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 124
ok 2 - All modules expected at t/53lean_startup.t line 125 loaded by DBIC: B, Carp, Class::Accessor::Grouped, Class::C3::Componentised, Devel::GlobalDestruction, Hash::Merge, List::Util, SQL::Abstract, Scalar::Util, Storable, Sub::Defer, Sub::Name, Sub::Quote, Try::Tiny, base, constant, mro, namespace::clean, overload
...
# Auto checked 10 references for leaks - none detected
# Looks like you failed 1 test of 7.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/7 subtests 

Test Summary Report
-------------------
t/53lean_startup.t (Wstat: 256 Tests: 7 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=1, Tests=7,  3 wallclock secs ( 0.04 usr  0.01 sys +  0.67 cusr  0.06 csys =  0.78 CPU)
Result: FAIL

[jkeenan]

This is the failure I get on blead on Linux:

$ bleadperl -v
This is perl 5, version 31, subversion 10 (v5.31.10 (v5.31.9-123-g8200912a00)) built for x86_64-linux
$ bleadprove -vb t/53lean_startup.t
t/53lean_startup.t .. 
#
not ok 1 - Unexpected require of 'MRO::Compat' by DBIx::Class::Componentised (/home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Componentised.pm line 7)

#   Failed test 'Unexpected require of 'MRO::Compat' by DBIx::Class::Componentised (/home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Componentised.pm line 7)'
#   at t/53lean_startup.t line 54.
# Require invoked at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/site_perl/5.31.10/Class/C3/Componentised.pm line 44
#     invoked as Class::C3::Componentised::BEGIN at /home/jkeenan/testing/blead/lib/perl5/site_perl/5.31.10/Class/C3/Componentised.pm line 44
#     invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/site_perl/5.31.10/Class/C3/Componentised.pm line 44
#     invoked as (eval) at (eval 1244) line 5
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 1243) line 4
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#     invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 137
#     invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 105
#     invoked as base::import at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Componentised.pm line 7
#     invoked as DBIx::Class::Componentised::BEGIN at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Componentised.pm line 7
#     invoked as (eval) at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Componentised.pm line 7
#     invoked as (eval) at (eval 1236) line 5
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 1235) line 4
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#     invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 137
#     invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 105
#     invoked as base::import at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class.pm line 23
#     invoked as DBIx::Class::BEGIN at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class.pm line 23
#     invoked as (eval) at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class.pm line 23
#     invoked as (eval) at (eval 1216) line 5
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 1215) line 4
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#     invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 137
#     invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 105
#     invoked as base::import at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Schema.pm line 6
#     invoked as DBIx::Class::Schema::BEGIN at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Schema.pm line 6
#     invoked as (eval) at /home/jkeenan/.cpanm/work/1584795218.1992/DBIx-Class-0.082841/blib/lib/DBIx/Class/Schema.pm line 6
#     invoked as (eval) at (eval 1208) line 5
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 1207) line 4
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#     invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 137
#     invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 105
#     invoked as base::import at t/lib/DBICTest/BaseSchema.pm line 6
#     invoked as DBICTest::BaseSchema::BEGIN at t/lib/DBICTest/BaseSchema.pm line 6
#     invoked as (eval) at t/lib/DBICTest/BaseSchema.pm line 6
#     invoked as (eval) at (eval 713) line 5
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 712) line 4
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#     invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 137
#     invoked as (eval) at /home/jkeenan/testing/blead/lib/perl5/5.31.10/base.pm line 105
#     invoked as base::import at t/lib/DBICTest/Schema.pm line 8
#     invoked as DBICTest::Schema::BEGIN at t/lib/DBICTest/Schema.pm line 8
#     invoked as (eval) at t/lib/DBICTest/Schema.pm line 8
#     invoked as (eval) at (eval 703) line 5
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 49
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at (eval 702) line 4
#     invoked as (eval) at t/lib/DBICTest/Util/OverrideRequire.pm line 120
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 16
#     invoked as main::__ANON__ at t/lib/DBICTest/Util/OverrideRequire.pm line 130
#     invoked as DBICTest::Util::OverrideRequire::__ANON__ at t/53lean_startup.t line 124
ok 2 - All modules expected at t/53lean_startup.t line 125 loaded by DBIC: B, Carp, Class::Accessor::Grouped, Class::C3::Componentised, Devel::GlobalDestruction, Hash::Merge, List::Util, SQL::Abstract, Scalar::Util, Storable, Sub::Defer, Sub::Name, Sub::Quote, Try::Tiny, base, constant, mro, namespace::clean, overload
...
# Auto checked 10 references for leaks - none detected
# Looks like you failed 1 test of 7.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/7 subtests 

Test Summary Report
-------------------
t/53lean_startup.t (Wstat: 256 Tests: 7 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=1, Tests=7,  3 wallclock secs ( 0.04 usr  0.01 sys +  0.67 cusr  0.06 csys =  0.78 CPU)
Result: FAIL

And running this through the debugger, I get (excerpt):

  DB<1> 
main::(t/53lean_startup.t:4):   my ($initial_inc_contents, $expected_dbic_deps, $require_sites);
  DB<1> 
main::(t/53lean_startup.t:130):   register_lazy_loadable_requires(qw(
main::(t/53lean_startup.t:131):     Moo
main::(t/53lean_startup.t:132):     Moo::Object
main::(t/53lean_startup.t:133):     Method::Generate::Accessor
main::(t/53lean_startup.t:134):     Method::Generate::Constructor
main::(t/53lean_startup.t:135):     Context::Preserve
main::(t/53lean_startup.t:136):   ));
  DB<1> 
main::(t/53lean_startup.t:98):    register_lazy_loadable_requires(qw(
main::(t/53lean_startup.t:99):      B
main::(t/53lean_startup.t:100):     constant
main::(t/53lean_startup.t:101):     overload
  DB<1> 
main::(t/53lean_startup.t:124):   require DBICTest::Schema;
  DB<1> 
#
not ok 1 - Unexpected require of 'MRO::Compat' by DBIx::Class::Componentised (blib/lib/DBIx/Class/Componentised.pm line 7)
#   Failed test 'Unexpected require of 'MRO::Compat' by DBIx::Class::Componentised (blib/lib/DBIx/Class/Componentised.pm line 7)'
#   at t/53lean_startup.t line 54.
main::(t/53lean_startup.t:125):   assert_no_missing_expected_requires();

[jkeenan]

The failure for CGI-ProgressBar looks like this:

Building and testing CGI-ProgressBar-0.05
cp lib/CGI/ProgressBar.pm blib/lib/CGI/ProgressBar.pm
PERL_DL_NONLAZY=1 "/home/jkeenan/testing/blead/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
Bareword "progress_bar" not allowed while "strict subs" in use at t/test.t line 27.
Bareword "update_progress_bar" not allowed while "strict subs" in use at t/test.t line 46.
Bareword "hide_progress_bar" not allowed while "strict subs" in use at t/test.t line 57.
Execution of t/test.t aborted due to compilation errors.
t/test.t ..
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 12/12 subtests

Test Summary Report
-------------------
t/test.t (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 12 tests but ran 0.
Files=1, Tests=0,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.03 cusr  0.00 csys =  0.05 CPU)
Result: FAIL
Failed 1/1 test programs. 0/0 subtests failed.

[jkeenan]

The failure for App-Framework-Lite looks like this:

Building and testing App-Framework-Lite-1.09
cp lib/App/Framework/Lite.pm blib/lib/App/Framework/Lite.pm
cp lib/App/Framework/Lite/Object.pm blib/lib/App/Framework/Lite/Object.pm
PERL_DL_NONLAZY=1 "/home/jkeenan/testing/blead/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'inc', 'blib/lib', 'blib/arch')" t/*.t
t/00-AAAA-Object.t .......... ok
Undefined subroutine &main::go called at t/00-Aliases-1.t line 7.
# Looks like your test exited with 255 before it could output anything.
t/00-Aliases-1.t ............ 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 3/3 subtests 
Undefined subroutine &main::go called at t/00-Aliases-2.t line 7.
# Looks like your test exited with 255 before it could output anything.
t/00-Aliases-2.t ............ 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 3/3 subtests 
Undefined subroutine &main::go called at t/00-Aliases-3.t line 7.
# Looks like your test exited with 255 before it could output anything.
t/00-Aliases-3.t ............ 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 3/3 subtests 
Undefined subroutine &main::go called at t/00-Aliases-4.t line 7.
# Looks like your test exited with 255 before it could output anything.
t/00-Aliases-4.t ............ 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 3/3 subtests 
t/00-boilerplate.t .......... ok
# Testing App::Framework::Lite 1.09, Perl 5.031010, /home/jkeenan/testing/blead/bin/perl
t/00-load.t ................. ok
Undefined subroutine &main::go called at t/00-Misc.t line 41.
# Looks like your test exited with 255 before it could output anything.
t/00-Misc.t ................. 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/1 subtests 
# Testing usage
t/01-Man.t .................. ok
# Testing usage
t/01-Mandev.t ............... ok
# Testing options
t/02-Options-1.t ............ ok
# Testing options
t/02-Options-2.t ............ ok
# Testing options expanded variables
t/02-Options-3.t ............ ok
# Testing options and args expanded variables
t/02-Options-4.t ............ ok
# Testing include path
t/03-Inc.t .................. ok
# Testing auto-use of common modules
t/03-Use.t .................. ok
# Testing args
t/04-Args.t ................. ok
# Testing args (array)
t/04-ArgsArray.t ............ ok
# Testing args (array no-check)
t/04-ArgsArray2.t ........... ok
# Testing args (open handles with defaults)
t/04-ArgsDefault.t .......... ok
# Testing args (open handles)
t/04-ArgsOpen.t ............. ok
# Testing args (array)
t/04-ArgsWild.t ............. ok
# Testing data
t/05-Data.t ................. ok
t/06-pod-coverage.t ......... ok
t/07-pod.t .................. ok
# Testing module embed

#   Failed test 'Embedded script with all options, run with run options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test1.pl line 10.
# '
#     expected: 'Can't open perl script "./t/test1.pl": No such file or directory
# '

#   Failed test 'Embedded script with all options, run with help options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test1.pl line 10.
# '
#     expected: 'Can't open perl script "./t/test1.pl": No such file or directory
# '

#   Failed test 'Embedded script with all options, run with man options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test1.pl line 10.
# '
#     expected: 'Can't open perl script "./t/test1.pl": No such file or directory
# '

#   Failed test 'Embedded script with no-comp options, run with run options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test1.pl line 10.
# '
#     expected: 'Can't open perl script "./t/test1.pl": No such file or directory
# '

#   Failed test 'Embedded script with no-comp options, run with help options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test1.pl line 10.
# '
#     expected: 'Can't open perl script "./t/test1.pl": No such file or directory
# '

#   Failed test 'Embedded script with no-comp options, run with man options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test1.pl line 10.
# '
#     expected: 'Can't open perl script "./t/test1.pl": No such file or directory
# '

#   Failed test 'Embedded script with all options, run with run options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test2.pl line 11.
# Loaded MyLib
# '
#     expected: 'Can't open perl script "./t/test2.pl": No such file or directory
# '

#   Failed test 'Embedded script with all options, run with help options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test2.pl line 11.
# Loaded MyLib
# '
#     expected: 'Can't open perl script "./t/test2.pl": No such file or directory
# '

#   Failed test 'Embedded script with all options, run with man options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test2.pl line 11.
# Loaded MyLib
# '
#     expected: 'Can't open perl script "./t/test2.pl": No such file or directory
# '

#   Failed test 'Embedded script with no-comp options, run with run options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test2.pl line 11.
# Loaded MyLib
# '
#     expected: 'Can't open perl script "./t/test2.pl": No such file or directory
# '

#   Failed test 'Embedded script with no-comp options, run with help options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test2.pl line 11.
# Loaded MyLib
# '
#     expected: 'Can't open perl script "./t/test2.pl": No such file or directory
# '

#   Failed test 'Embedded script with no-comp options, run with man options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test2.pl line 11.
# Loaded MyLib
# '
#     expected: 'Can't open perl script "./t/test2.pl": No such file or directory
# '

#   Failed test 'Embedded script with all options, run with run options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test3.pl line 11.
# '
#     expected: 'Can't open perl script "./t/test3.pl": No such file or directory
# '

#   Failed test 'Embedded script with all options, run with help options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test3.pl line 11.
# '
#     expected: 'Can't open perl script "./t/test3.pl": No such file or directory
# '

#   Failed test 'Embedded script with all options, run with man options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test3.pl line 11.
# '
#     expected: 'Can't open perl script "./t/test3.pl": No such file or directory
# '

#   Failed test 'Embedded script with no-comp options, run with run options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test3.pl line 11.
# '
#     expected: 'Can't open perl script "./t/test3.pl": No such file or directory
# '

#   Failed test 'Embedded script with no-comp options, run with help options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test3.pl line 11.
# '
#     expected: 'Can't open perl script "./t/test3.pl": No such file or directory
# '

#   Failed test 'Embedded script with no-comp options, run with man options'
#   at t/08-embed.t line 67.
#          got: 'Undefined subroutine &main::go called at t/embed/test3.pl line 11.
# '
#     expected: 'Can't open perl script "./t/test3.pl": No such file or directory
# '
# Looks like you failed 18 tests of 18.
t/08-embed.t ................ 
Dubious, test returned 18 (wstat 4608, 0x1200)
Failed 18/18 subtests 
0 at t/10-Feature-Run.t line 137.
t/10-Feature-Run.t .......... ok
t/20-Feature-Logging.t ...... ok
t/20-Feature-Run-Logging.t .. ok

Test Summary Report
-------------------
t/00-Aliases-1.t          (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 3 tests but ran 0.
t/00-Aliases-2.t          (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 3 tests but ran 0.
t/00-Aliases-3.t          (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 3 tests but ran 0.
t/00-Aliases-4.t          (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 3 tests but ran 0.
t/00-Misc.t               (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
t/08-embed.t              (Wstat: 4608 Tests: 18 Failed: 18)
  Failed tests:  1-18
  Non-zero exit status: 18
Files=29, Tests=435, 13 wallclock secs ( 0.15 usr  0.02 sys +  3.95 cusr  0.40 csys =  4.52 CPU)
Result: FAIL
Failed 6/29 test programs. 18/435 subtests failed.
Makefile:780: recipe for target 'test_dynamic' failed
make: *** [test_dynamic] Error 255
-> FAIL Installing App::Framework::Lite failed. See /home/jkeenan/.cpanm/work/1584805007.11488/build.log for details. Retry with --force to force install it.

[dur-randir]

Bisect points to ad89278aa25475fb03971aec66692e18e35d9c07 is the first bad commit

commit ad89278aa25475fb03971aec66692e18e35d9c07
Author: David Mitchell <davem@iabyn.com>
Date:   Thu Mar 12 14:14:24 2020 +0000

    fixup to "avoid identical stack traces" - try 2

    GH #15109, #17567

    [ this commit was originally applied as v5.31.9-121-gfb8188b84d, but was
    quickly reverted by v5.31.9-124-g6311900a66. I'm now -re-applying it,
    but with a 'SAVEFREEOP(PL_curcop)' added, which was missing from the
    original commit. ]

    My original fix for this issue, v5.31.6-141-gf2f32cd638
    made a shallow copy of &PL_compiling. However, for non-default
    warning bits, this made two COPs share the malloced() cop_warnings,
    and bad things ensured. In particular this was flagged up in:

        GH #17567: "BBC: AYOUNG/OpenVZ-0.01.tar.gz"

    The fix in this commit is to do a deep copy of the COP using
    newSTATEOP().

[jkeenan]

Bisect points to ad89278 is the first bad commit

commit ad89278aa25475fb03971aec66692e18e35d9c07
Author: David Mitchell <davem@iabyn.com>
Date:   Thu Mar 12 14:14:24 2020 +0000

    fixup to "avoid identical stack traces" - try 2

Confirmed. @iabyn, can you take a look?

Thank you very much. Jim Keenan

[iabyn]

On Sat, Mar 21, 2020 at 08:44:14AM -0700, James E Keenan wrote:

The failure for CGI-ProgressBar looks like this: ... Bareword "progress_bar" not allowed while "strict subs" in use at t/test.t line 27.

I looked at this distro first, as it seemed to have the least dependencies. I haven't looked at the others yet.

CGI::ProgressBar appears to be relying on the bug (since fixed) in caller() to work out what package to do its exports to. It can be reduced to:

$ cat Foo.pm

package Foo;

BEGIN {
    my $c = caller(0);
    print "caller=[$c]\n";
}
1;

$ perl5300   -e'use Foo'
caller=[main]
$ perl53110  -e'use Foo'
caller=[Foo]

So the package reported for the caller of the BEGIN has changed from 'main' to 'Foo'. I think the change is correct. The BEGIN is being called from the Foo.pm file, within the 'Foo' package declaration. There's an implicit outer BEGIN too (generated by the 'use'), but that's irrelevant as caller(0) should be showing the inner BEGIN.

So I think this is a correct bug fix in perl as far as CGI::ProgressBar is concerned.

PS this distro is at version 0.05 and last had a release about 10 years ago.

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

[jkeenan]

On 3/21/20 1:46 PM, iabyn wrote:

On Sat, Mar 21, 2020 at 08:44:14AM -0700, James E Keenan wrote:

The failure for CGI-ProgressBar looks like this: ... Bareword "progress_bar" not allowed while "strict subs" in use at t/test.t line 27.

I looked at this distro first, as it seemed to have the least dependencies. I haven't looked at the others yet.

CGI::ProgressBar appears to be relying on the bug (since fixed) in caller() to work out what package to do its exports to. It can be reduced to:

$ cat Foo.pm

package Foo;

BEGIN { my $c = caller(0); print "caller=[$c]\n"; } 1;

$ perl5300 -e'use Foo' caller=[main] $ perl53110 -e'use Foo' caller=[Foo]

So the package reported for the caller of the BEGIN has changed from 'main' to 'Foo'. I think the change is correct. The BEGIN is being called from the Foo.pm file, within the 'Foo' package declaration. There's an implicit outer BEGIN too (generated by the 'use'), but that's irrelevant as caller(0) should be showing the inner BEGIN.

So I think this is a correct bug fix in perl as far as CGI::ProgressBar is concerned.

PS this distro is at version 0.05 and last had a release about 10 years ago.

Yes, CGI-ProgressBar is old and so I'm not too worried about it. Same for App-Framework-Lite. Have you had a chance to look at DBIx::Class?

Thank you very much. Jim Keenan

[iabyn]

On Sat, Mar 21, 2020 at 10:56:20AM -0700, James E Keenan wrote:

On 3/21/20 1:46 PM, iabyn wrote: Yes, CGI-ProgressBar is old and so I'm not too worried about it. Same for App-Framework-Lite. Have you had a chance to look at DBIx::Class?

To repeat what I said above:

I looked at this distro first, as it seemed to have the least dependencies. I haven't looked at the others yet.

-- You never really learn to swear until you learn to drive.

[jkeenan]

On 3/21/20 3:12 PM, iabyn wrote:

On Sat, Mar 21, 2020 at 10:56:20AM -0700, James E Keenan wrote:

On 3/21/20 1:46 PM, iabyn wrote: Yes, CGI-ProgressBar is old and so I'm not too worried about it. Same for App-Framework-Lite. Have you had a chance to look at DBIx::Class?

To repeat what I said above:

I looked at this distro first, as it seemed to have the least dependencies. I haven't looked at the others yet.

Sorry, I overlooked that.

[iabyn]

On Sat, Mar 21, 2020 at 04:06:57PM -0700, Sawyer X wrote:

DBIx::Class is surely the critical part here.

I looked at the other distro first simply because it was simpler and would thus be easier to diagnose. If it turned out to be a bug in perl, then I could quickly fix perl, then see if the issue went away for DBIx::Class etc too. Since CGI-ProgressBar turned out not to be a perl issue, I'm now looking at DBIx::Class. My preliminary thought is that its just a bug in one test script that expects certain things from caller().

-- Music lesson: a symbiotic relationship whereby a pupil's embellishments concerning the amount of practice performed since the last lesson are rewarded with embellishments from the teacher concerning the pupil's progress over the corresponding period.

[iabyn]

On Sun, Mar 22, 2020 at 03:22:03AM -0700, iabyn wrote:

On Sat, Mar 21, 2020 at 04:06:57PM -0700, Sawyer X wrote:

DBIx::Class is surely the critical part here.

I looked at the other distro first simply because it was simpler and would thus be easier to diagnose. If it turned out to be a bug in perl, then I could quickly fix perl, then see if the issue went away for DBIx::Class etc too. Since CGI-ProgressBar turned out not to be a perl issue, I'm now looking at DBIx::Class. My preliminary thought is that its just a bug in one test script that expects certain things from caller().

I've looked a lot deeper into the one test script in DBIx::Class which fails: t/53lean_startup.t.

I'm almost 100% certain its a bug in the script, but since I don't understand what the script is trying to test, I can't venture a suggested fix.

It's overriding perl's require with a custom sub which goes up the caller($i++) stack till it finds something of interest, then gives an error if that interesting thing isn't what it expected. This will of course be called from within nested use/BEGIN/require's, so perl now gives different results, which is tripping up the test script. In particular on the call to the sub which now fails, caller(2)[0] is now (correctly) Class::C3::Componentised rather than 'main'. This means that the require function now stops its search at caller(12) rather than caller(2), then fails the two conditions

$caller[0] =~ /^DBIx::Class/;
(caller($up))[3] =~ /\Q$caller[0]/;

-- Never work with children, animals, or actors.

[iabyn]

Finally, App-Framework-Lite was relying on the bug in caller() to import something into the namespace where 'use App::Framework::Lite' was located. The following diff makes all tests pass on blead.

diff -u lib/App/Framework/Lite.pm.orig lib/App/Framework/Lite.pm --- lib/App/Framework/Lite.pm.orig 2020-03-22 19:27:23.859910042 +0000 +++ lib/App/Framework/Lite.pm 2020-03-22 19:48:05.087337602 +0000 @@ -1104,7 +1104,9 @@

@NO-EMBED END

## Get caller information

• my ($package, $filename, $line, $subr, $has_args, $wantarray) = caller(0) ;
• my $depth = $] < 5.031007 ? 0 : 2;

• my ($package, $filename, $line, $subr, $has_args, $wantarray) = caller($depth) ;

  Add a couple of useful function calls into the caller namespace

  {

-- Standards (n). Battle insignia or tribal totems.

[xsawyerx]

Sorry I keep responding to earlier comments. I'll ping the author.

[ribasushi]

On a very cursory glance https://github.com/Perl/perl5/issues/17663#issuecomment-602262782 looks like an outright regression in perl that should be fixed ( a proper bugfix likely wouldn't be predicated on $]-gating ). Before making any changes to DBIC I will need to analyze this way more substantially.

As many others in our profession, I am currently heads down busy keeping my job. Thus I am not likely to be able to dig further until early May. As there are multiple failures related to this ( not just DBICs ) there is hope this will be reverted by then. If this change stays: I will find the time to ship a workaround shortly before RCs start rolling off the pipeline.

Cheers

[shadowcat-mst]

BEGIN is executed directly during compilation - so I'd argue that this change, while technically more correct on an abstract level, massively violates user expectations and at least for BEGIN blocks needs to be reverted.

@xsawyerx free opinion, worth exactly what you paid, but POLS/DWIM sayeth the old behaviour is way more ergonomic IMO

[xsawyerx]

On a very cursory glance #17663 (comment) looks like an outright regression in perl that should be fixed ( a proper bugfix likely wouldn't be predicated on $]-gating ). Before making any changes to DBIC I will need to analyze this way more substantially.

[...] Thus I am not likely to be able to dig further until early May. As there are multiple failures related to this ( not just DBICs ) there is hope this will be reverted by then. If this change stays: I will find the time to ship a workaround shortly before RCs start rolling off the pipeline.

Cheers

I appreciate you took the time for a cursory look at this during this time. Based on your feedback and @shadowcat-mst's, we will review this fix once more.

FWIW, I have no interest to ship a Perl that breaks DBIx::Class.

[shadowcat-mst]

@iabyn the more I think about this the more I think our original idea of the logical semantics - i.e. the one you posted upthread and which at first reading I found convincing - was unfortunately mistaken. Lemme go through why I think I was wrong and we'll see if you agree:

Given:

1) A BEGIN block is just an alias for 'sub BEGIN { ... }' 2) The thing that's special about sub BEGIN is its phaser-ness causing immediate invocation 3) Physically, caller(0) provides access to the stack frame that invoked the current subroutine 4) Logically, caller(0) answers the question "what called me?"

The thing that seems like the crux to me is the fact that the compiler isn't something that, from perl space (userland, as it were), actually exists as such.

If you look at something like Class::XSAccessor it finds its calling op to be able to modify it, which to me implies that we should be thinking about the calling op and its associated stack frame and for caller() info the OP_NEXTSTATE so associated.

When a 'sub BEGIN' is fired during compilation, the NEXTSTATE responsible for this happening is the one preceding the require() (or eval) call, and the only thing the sub is sharing with the currently-being-compiled code is that its OUTSIDE pad is the one in the process of being assembled.

So while lexically the 'sub BEGIN' is a child of the scope it's found within, dynamically it's still a child of the thing that called require().

We can observe more evidence for this by considering

sub foo {
    BEGIN { ... }
    ...
}

where it's a lexical child of 'sub foo', but it would make no sense at all to treat 'sub foo' as the caller, because foo() isn't currently being invoked. Similarly, the body of the file isn't yet being invoked, so IMO can't logically participate in the call stack on a dynamic basis.

This also fits with the special case behaviour of caller() when invoked inside package DB - the file isn't executing so there's no stack frame so there's no @_ to populate @DB::args from - so again, the only thing that makes logical sense is for the logical caller to be the thing that called require().

So I think the subtle but important distinction here is that when you said

The BEGIN is being called from the Foo.pm file, within the 'Foo' package declaration.

what's actually happpening is:

The BEGIN is being called during compilation of the Foo.pm file, with the current stash set to 'Foo', but as with the runtime of the top level of Foo.pm, it's being called from the require() operation that's compiling (and then running) the file.

Ass-u-ming this argument holds, that means that this change is, unfortunately, a logical/semantic regression as well as a POLA/DWIM violation, and the previous behaviour of caller() was actually correct and should thus be restored.

I've been trying to break my own logic here for a couple of days, and have mostly only managed to add extra nuances to it that support the case, but that still doesn't mean I'm right of course. I'd be most appreciative if @iabyn, @xsawyerx and anybody else who's been thinking about this could kick the metaphorical tires of my reasoning and tell me if they can see any logical flaws I've missed.

After all, in honour of my initials' expansion in french, this needs to be a Socially Tested Decision :D

[xsawyerx]

This is one of the two problems that are making me consider delaying the release of the next version.

I reviewed your arguments, and I think they are compelling, but I decided I view it differently. Let me try to explain.

This seems to me like confusion between the initiator of the current stack and the current stack's caller.

• We use caller() (as its name) to receive the caller.
• We assume the previous stack frame is also the initiator of the current stack frame.
• Those are not necessarily the same.

In this case, we found the edge case in which there's an initiator (the require), which passes it on to the package (the current caller()) that triggers the BEGIN in it. The package is, thus, the calling class.

When I read it as such, it makes sense.

If I look at the following in Perl < 5.31.10:

$ cat Foo.pm
package Foo;

BEGIN {
    my ($pkg, $filename, $line) = caller(0);
    print "pkg = $pkg\n"
        . "filename = $filename\n"
        . "line = $line\n";
}
1;

$ perl -I. -MFoo -e1
pkg = main
filename = Foo.pm
line = 5

This seems okay at first: main loads Foo, so Foo sees main as the caller. But if I look at the filename and line, this is confusing. It's telling me main is the caller, but it also tells me Foo.pm the caller. Here I can see that it tells me using $pkg who the initiator was (main) and with the other variables ($filename and $line) it says who the actual caller was.

From this perspective, the only consistent way to consider the caller is to have this fix that eliminates the confusion between initiator and caller.

Hopefully, this makes sense.

Having given all of this prelude, I am leaning toward undoing this fix temporarily for this release and reinstating it in the next release. The reason is that breaking DBIx::Class is unacceptable to me and the maintainer rightfully cannot commit to making the necessary updates by next month. I don't wish to push anyone to this position during these times, so it might just be safer to undo this temporarily.

Thoughts?

[vpit]

I disagree. caller is documented as returning the "context of the current subroutine call", and that's what the old implementation does, as mst explained. It's therefore consistent with itself.

I suggest amending perldoc -f caller to explain the difference between caller(0) and __PACKAGE__.

[xsawyerx]

Currently, the caller() reports one package, but the file and number of a different file and package. I don't see this as correct.

[shadowcat-mst]

@xsawyerx I confess I hadn't noticed the file/line number thing but if anything I'd resolve that inconsistency the other way, given everything else I've said :)

Also, hrm, your initiator versus caller argument is interesting and I think that we may be in a situation where much like say euclidean versus non-euclidean geometry, both forms of calculus are completely logically consistent and a solid mathematics can be built atop either and what we're really trying to figure out is which one best matches reality us our users actually inhabit it.

However what I definitely do think is that even if I turn out to be wrong (a possibility I don't like to admit to but am at least willing to consider in the abstract) you're right that it's a bit late now for people to compensate for the change before you ship.

So I would amend your conclusion from

I am leaning toward undoing this fix temporarily for this release and reinstating it in the next release.

to "undo the change for this release, get this release out the door, then we can (metaphorically) sit down for a cuppa and discuss it at length and make a final decision by .2 or .3 of the cycle so we can document and shake things out either way."

i.e. I think we're in agreement that "back it out for now, focus on shipping without it" is the absolutely correct next step, and what the correct next step after that is can be deferred.

[khwilliamson]

Commits are now reverted in blead. Is this no longer a blocker?

[shadowcat-mst]

@khwilliamson I believe you're correct but cpantesters/etc. will likely be a more reliable confirmation thereof.

[xsawyerx]

[...]

i.e. I think we're in agreement that "back it out for now, focus on shipping without it" is the absolutely correct next step, and what the correct next step after that is can be deferred.

Indeed. I did not reply yet, but we did review it and decided to revert, which @khwilliamson updated about.

I'm happy to discuss this after 5.32 and see how we decide to go on this. :)

[demerphq]

I wanted to comment on the assertion that the old behavior was "correct". I find this a remarkable position to take since it produces clear anomalies in the stack trace attributing actions to modules that absolutely could not have been correct.

$ perl -I. -MA -e1 in C at C.pm line 3. require C.pm called at B.pm line 1 main::BEGIN() called at C.pm line 0 eval {...} called at C.pm line 0 require B.pm called at A.pm line 1 main::BEGIN() called at C.pm line 0 eval {...} called at C.pm line 0 require A.pm called at -e line 0 main::BEGIN() called at C.pm line 0 eval {...} called at C.pm line 0 Compilation failed in require at B.pm line 1. BEGIN failed--compilation aborted at B.pm line 1. Compilation failed in require at A.pm line 1. BEGIN failed--compilation aborted at A.pm line 1. Compilation failed in require. BEGIN failed--compilation aborted.

Notice the bottom of the stack say eval {} called at C.pm line 0.

The BOTTOM of the stack.

Notice how many times that 'eval {...} called at C.pm line 0' is output. There is no way that can be correct.

Also note that BEGIN blocks, be they autogenerated by Perl itself as part of a use, or explicit ones are documented to execute exactly once and cannot be recursive. So how can it be "correct" that the same stack BEGIN be referenced multiple times in the stack like this? It doesn't make sense.

This incorrectness causes real inconvenience to even serious Perl hackers when the stack trace is very large. Every BEGIN but one is incorrect. This leads to people debugging the wrong thing and getting thoroughly confused.

$ cat [ABC].pm package A; use B; END package B; use C; END package C; use Carp; confess("in C"); END

[Leont]

This ticket raises the question «what is correctness». The current behavior is truthful, but not intuitive. This discussion really seems to be about which of those two values are more relevant for correctness.

[demerphq]

Consider the following code and output:

norole:yorton@psykopsis:~/stack_bug$ cat Mod{A,B,C}.pm package ModA;

use Carp qw(confess); BEGIN {confess "ModA not allowed" if $ENV{DIE_IN} eq "A" }

use ModB;

1; END package ModB;

use Carp qw(confess); BEGIN {confess "ModB not allowed" if $ENV{DIE_IN} eq "B" }

use ModC;

1; END package ModC;

use Carp qw(confess);

confess "Cannot load ModC";

1; END norole:yorton@psykopsis:~/stack_bug$ DIE_IN=A perl -I. -MModA -e1 ModA not allowed at ModA.pm line 4. ModA::BEGIN() called at ModA.pm line 4 eval {...} called at ModA.pm line 4 require ModA.pm called at -e line 0 main::BEGIN() called at ModA.pm line 4 eval {...} called at ModA.pm line 4 BEGIN failed--compilation aborted at ModA.pm line 4. Compilation failed in require. BEGIN failed--compilation aborted.

norole:yorton@psykopsis:~/stack_bug$ DIE_IN=B perl -I. -MModA -e1 ModB not allowed at ModB.pm line 4. ModB::BEGIN() called at ModB.pm line 4 eval {...} called at ModB.pm line 4 require ModB.pm called at ModA.pm line 6 ModA::BEGIN() called at ModB.pm line 4 eval {...} called at ModB.pm line 4 require ModA.pm called at -e line 0 main::BEGIN() called at ModB.pm line 4 eval {...} called at ModB.pm line 4 BEGIN failed--compilation aborted at ModB.pm line 4. Compilation failed in require at ModA.pm line 6. BEGIN failed--compilation aborted at ModA.pm line 6. Compilation failed in require. BEGIN failed--compilation aborted.

norole:yorton@psykopsis:~/stack_bug$ DIE_IN=C perl -I. -MModA -e1 Cannot load ModC at ModC.pm line 5. require ModC.pm called at ModB.pm line 6 ModB::BEGIN() called at ModC.pm line 0 eval {...} called at ModC.pm line 0 require ModB.pm called at ModA.pm line 6 ModA::BEGIN() called at ModC.pm line 0 eval {...} called at ModC.pm line 0 require ModA.pm called at -e line 0 main::BEGIN() called at ModC.pm line 0 eval {...} called at ModC.pm line 0 Compilation failed in require at ModB.pm line 6. BEGIN failed--compilation aborted at ModB.pm line 6. Compilation failed in require at ModA.pm line 6. BEGIN failed--compilation aborted at ModA.pm line 6. Compilation failed in require. BEGIN failed--compilation aborted.

---

So, can you explain to me how that output can be truthful? It isnt even consistent run to run.

When we make ModA die we see:

ModA not allowed at ModA.pm line 4. ModA::BEGIN() called at ModA.pm line 4 eval {...} called at ModA.pm line 4

This all makes sense and lines with the actual files. I would agree this output is "truthful".

When we make ModB die we see:

require ModA.pm called at -e line 0 main::BEGIN() called at ModB.pm line 4 eval {...} called at ModB.pm line 4

So now apparently ModA was loaded from a line in a module that doesnt reference ModA at all.

When we make ModC die we see:

require ModA.pm called at -e line 0 main::BEGIN() called at ModC.pm line 0 eval {...} called at ModC.pm line 0

So, the main::BEGIN() was called at ModC.pm which doesnt contain any code in the namespace main.

I do not understand how anyone can argue that mess makes sense, or can be considered in any way truthful or correct. I can understand virtually any argument other than the current is correct or truthful. It is simply not. BEGIN blocks are called exactly once. The same BEGIN block cannot be present twice in the call stack ever.

Also note that errors reported by require are correct and consistent across the invocations, because they aren't affected by the global var involved here (they set it up). If you look at the compilation aborted messages they are correct:

Compilation failed in require at ModB.pm line 6. BEGIN failed--compilation aborted at ModB.pm line 6. Compilation failed in require at ModA.pm line 6. BEGIN failed--compilation aborted at ModA.pm line 6.

This is purely because the var used to track the source of the BEGIN blocks for EVERY begin created by required is being shared. I do not understand how anyone can argue that is correct. Please help me understand.

Yves

On Thu, 29 Oct 2020 at 20:06, Leon Timmermans notifications@github.com wrote:

This ticket raises the question «what is correctness». The current behavior is truthful, but not intuitive. This discussion really seems to be about which of those two values are more relevant for correctness.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Perl/perl5/issues/17663#issuecomment-718960416, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAZ5R5IYLIY3MJXPRDDFE3SNG4KZANCNFSM4LQ3GRUA .

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[jkeenan]

Given that http://matrix.cpantesters.org/?dist=DBIx-Class%200.082842 is showing nearly all green on nearly all 5.32. and 5.33. releases, do we need to keep this ticket open?

Thank you very much. Jim Keenan

[demerphq]

Does that mean the underlying bug has been fixed and DBIx class has been changed not to depend on the buggy stack?

cheers, Yves

On Thu, 11 Feb 2021 at 02:46, James E Keenan notifications@github.com wrote:

Given that http://matrix.cpantesters.org/?dist=DBIx-Class%200.082842 is showing nearly all green on nearly all 5.32. and 5.33. releases, do we need to keep this ticket open?

Thank you very much. Jim Keenan

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[jkeenan]

[Re-arranging to avoid top-posting]

On Thu, 11 Feb 2021 at 02:46, James E Keenan @.**> wrote: Given that http://matrix.cpantesters.org/?dist=DBIx-Class%200.082842 is showing nearly all green on nearly all 5.32. and 5.33.* releases, do we need to keep this ticket open?

Does that mean the underlying bug has been fixed and DBIx class has been changed not to depend on the buggy stack? cheers, Yves

I do not know. However, if the distribution reported failing in a BBC ticket gets healthy again, then that ticket should, cet. par., be closed and a new ticket should be opened for any problems in Perl cited within the old ticket.

Not taking that approach would likely mean that this ticket would remain open indefinitely.

Thank you very much. Jim Keenan

[haarg]

Does that mean the underlying bug has been fixed and DBIx class has been changed not to depend on the buggy stack? cheers, Yves

DBIx-Class has not been updated. The change in perl was reverted, and has not been reapplied.

[ribasushi]

@demerphq moreover: I find your arguments that this is a case of "reliance on a buggy stack" null and void. There are no plans to make any changes in DBIC regarding this either now or in the future. As per https://github.com/Perl/perl5/issues/17663#issuecomment-607747119, if perl-core decides to reintroduce this breaking change and ship it in a stable release - I will add a workaround to DBIC provided there is popular demand. Cheers!

[demerphq]

So we have given DBIC veto power over fixing internal bugs now?

I object!

Yves

On Thu, 11 Feb 2021 at 18:29, Peter Rabbitson notifications@github.com wrote:

@demerphq moreover: I find your arguments that this is a case of "reliance on a buggy stack" null and void. There are no plans to make any changes in DBIC regarding this either now or in the future. As per #17663 (comment), if perl-core decides to reintroduce the change and ship it in a stable release - I will add a workaround to DBIC provided there is popular demand. Cheers!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[duncand]

This matter has been raised again today on perl5-porters.

I feel that the bug SHOULD be fixed in Perl 5.35.x and 5.36.0+, and DBIC should be updated to not rely on the broken behaviour of older Perl versions.

[eserte]

DBIC has now patches for this problem (if I understand https://github.com/Perl/perl5/issues/19452 correctly), but what about CGI-ProgressBar-0.05 and App-Framework-Lite-1.09 which started to fail again with perl 5.35.9?

[demerphq]

On Sun, 13 Mar 2022 at 10:15, Slaven Rezić @.***> wrote:

DBIC has now patches for this problem (if I understand #19452 https://github.com/Perl/perl5/issues/19452 correctly), but what about CGI-ProgressBar-0.05 and App-Framework-Lite-1.09 which started to fail again with perl 5.35.9?

They need to be fixed to not rely on the buggy behavior that this patch fixed.

Graham Knopp has been doing a lot of fixing related to this, and I will also look into it. Do we have BBC tickets for them?

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[demerphq]

On Sun, 13 Mar 2022 at 10:44, demerphq @.***> wrote:

On Sun, 13 Mar 2022 at 10:15, Slaven Rezić @.***> wrote:

DBIC has now patches for this problem (if I understand #19452 correctly), but what about CGI-ProgressBar-0.05 and App-Framework-Lite-1.09 which started to fail again with perl 5.35.9?

They need to be fixed to not rely on the buggy behavior that this patch fixed.

Graham Knopp has been doing a lot of fixing related to this, and I will also look into it. Do we have BBC tickets for them?

CGI::ProgressBar unilaterally installs functions into caller(0) inside of a BEGIN. That means it's been broken since it was released. If you tried to load it from two modules only one would get the imports. It also hasn't been updated since 2010 and this issue has already been reported to the author in 2020. Not sure what to do about that. It looks like it is abandonware.

I am not sure what is wrong with App::Framework yet.

cheers, Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[haarg]

App::Framework::Lite installs subs into caller(0) in a BEGIN block, so it was already broken before this change. It also has an import method. It's not obvious why they didn't do the sub installation in the import, but that should be a trivial fix if the module is not abandoned.

[jkeenan]

App::Framework::Lite installs subs into caller(0) in a BEGIN block, so it was already broken before this change. It also has an import method. It's not obvious why they didn't do the sub installation in the import, but that should be a trivial fix if the module is not abandoned.

I added test failure output upstream at https://rt.cpan.org/Ticket/Display.html?id=132190.

[rjbs]

I am closing this. The known breakage has been addressed. (#19452 exist but is a separate issue.) I don't really expect we'll see the non-DBIx-Class libraries fixed, because I don't expect they're in use, but this issue will not block release.