Skip Menu |

This queue is for tickets about the Module-Runtime CPAN distribution.

Report information
The Basics
Id: 74895
Status: resolved
Priority: 0/
Queue: Module-Runtime

People
Owner: Nobody in particular
Requestors: paul [...] city-fan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.012
Fixed in: (no value)



Subject: _WORK_AROUND_BROKEN_MODULE_STATE fix in 0.012 breaks the Class::Load test suite with Perl < 5.10
After upgrading Module::Runtime to 0.12, I found that the Class::Load test suite failed on perl < 5.10 (well, it passed on 5.10.0 and failed on 5.8.8 and anything earlier I tried), like this: $ make test RELEASE_TESTING=1 PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/000-load......................# Using PP implementation ok t/001-is-class-loaded...........ok t/002-try-load-class............ok t/003-load-class................ok t/004-load-double...............ok t/005-load-optional............. # Failed test 'Loading a broken class breaks' # at t/005-load-optional.t line 31. # undef # ne # undef # Looks like you failed 1 test of 8. dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 3 Failed 1/8 tests, 87.50% okay t/006-returned-error............ok t/007-first-existing............ok t/008-gvstash-bug...............ok t/009-invalid-module-name.......ok t/010-isa-false-positive........ # Failed test 'Class which calls die is reported as an error' # at t/010-isa-false-positive.t line 17. # undef # ne # undef # Failed test 'Class populates @ISA in BEGIN then dies - error on load' # at t/010-isa-false-positive.t line 38. # undef # ne # undef # Failed test 'Class with a syntax error causes an error' # at t/010-isa-false-positive.t line 59. # undef # ne # undef # Failed test 'Class with a syntax error causes an error (second attempt)' # at t/010-isa-false-positive.t line 67. # undef # ne # undef # Looks like you failed 4 tests of 6. dubious Test returned status 4 (wstat 1024, 0x400) DIED. FAILED tests 1, 3, 5-6 Failed 4/6 tests, 33.33% okay t/011-without-xs................ok t/012-without-implementation....ok t/release-cpan-changes..........skipped all skipped: Test::CPAN::Changes required for this test t/release-eol...................ok t/release-no-tabs...............ok t/release-pod-coverage..........ok t/release-pod-linkcheck.........skipped all skipped: Test::Pod::LinkCheck required for testing POD t/release-pod-no404s............skipped all skipped: Test::Pod::No404s required for testing POD t/release-pod-spell.............ok t/release-pod-syntax............ok Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- t/005-load-optional.t 1 256 8 1 12.50% 3 t/010-isa-false-positive.t 4 1024 6 4 66.67% 1 3 5-6 3 tests skipped. Failed 2/21 test scripts, 90.48% okay. 5/187 subtests failed, 97.33% okay. Now all of these failing tests are doing isnt(exception{...},undef), which Test::Fatal has just been updated to warn against doing, bit they do still work with 0.012 on more recent perls. I tried reverting bits of the Module::Runtime changes to figure out what had triggered this breakage, and making this change got the Class::Load test suite working again: --- Module-Runtime/lib/Module/Runtime.pm +++ Module-Runtime/lib/Module/Runtime.pm @@ -306,16 +306,7 @@ # %^H state leaking into each required module, polluting the # module's lexical state. local %^H if _WORK_AROUND_HINT_LEAKAGE; - if(_WORK_AROUND_BROKEN_MODULE_STATE) { - my $notional_filename = &module_notional_filename; - my $guard = bless([ $notional_filename ], - "Module::Runtime::__GUARD__"); - my $result = require($notional_filename); - pop @$guard; - return $result; - } else { - return scalar(require(&module_notional_filename)); - } + return scalar(require(&module_notional_filename)); } =back However, this of course broke the Module::Runtime test suite, which is checking that these changes are in place. I'm now out of my depth and dn't know how best to proceed. Is this an actual Module::Runtime bug or would it be better to get the Class::Load test suite fixed?
Subject: Re: [rt.cpan.org #74895] _WORK_AROUND_BROKEN_MODULE_STATE fix in 0.012 breaks the Class::Load test suite with Perl < 5.10
Date: Sun, 12 Feb 2012 17:16:01 +0000
To: "paul [...] city-fan.org via RT" <bug-Module-Runtime [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
paul@city-fan.org via RT wrote: Show quoted text
> Is this an actual Module::Runtime bug or >would it be better to get the Class::Load test suite fixed?
I can't immediately answer this definitively. I'll look into it with Class::Load's test suite. -zefram
Subject: Re: [rt.cpan.org #74895] _WORK_AROUND_BROKEN_MODULE_STATE fix in 0.012 breaks the Class::Load test suite with Perl < 5.10
Date: Sun, 12 Feb 2012 17:42:18 +0000
To: "paul [...] city-fan.org via RT" <bug-Module-Runtime [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
paul@city-fan.org via RT wrote: Show quoted text
> Is this an actual Module::Runtime bug or >would it be better to get the Class::Load test suite fixed?
Turns out neither. The bug, such as it is, is in Class::Load::load_optional_class: # My testing says that if its in INC, the file definitely exists # on disk. In all versions of Perl. The value isn't reliable, # but it existing is. my $file = module_notional_filename($class); return 0 unless exists $INC{$file}; That's a really helpful comment, because it sets out exactly the assumption that turns out to not be true. From Perl 5.9 onwards all is good: in %INC with defined value means the module existed and loaded OK, in %INC with undefined value means the module existed and had an error, and not in %INC means the module didn't exist. Before Perl 5.9, the natural core behaviour also obeys the comment, but it's broken: an element in %INC always has defined value, means the module existed, but doesn't actually say whether there was an error, but is treated by the core as meaning the module loaded OK. Thus the core bug of mistaking an errored module for an OK module when it is re-required. Because the existed-but-broken state can't be represented pre-5.9, the standard workaround for the bug is to delete the %INC element if a module load errored. So now having an element in %INC means the module existed and loaded OK (as on 5.9+), and not having an element in %INC means either the module didn't exist or it had an error. That violates the expectation set out in C:L's comment. It could be argued that this makes the standard workaround broken. But working around it is fairly important for other purposes, so I think it's more useful to see the workaround behaviour as something that C:L ought to accept, and indeed ought to reliably provide (as it now does via M:R) in order to avoid misleading other code about errored modules. Instead you need a better way to distinguish missing modules from erroneous modules. Happily, M:R already has such a mechanism. use_package_optimistically() does pretty much what load_optional_class() wants. It used to have nasty complicated behaviour, matching the nasty complicated behaviour of base.pm, but base.pm moved to much more satisfactory semantics and u_p_o() has moved with it. I doubt they'll semantically change more from here. Current u_p_o() attempts to load a module, and signals error if the module existed with error, but does not signal an error if the module was non-existent. It also has a version checking feature which seems to match part of load_optional_class(). So, in summary, your problem arising from using Module::Runtime can be solved by using MOAR Module::Runtime. -zefram
Subject: Re: [rt.cpan.org #74895] _WORK_AROUND_BROKEN_MODULE_STATE fix in 0.012 breaks the Class::Load test suite with Perl < 5.10
Date: Sun, 12 Feb 2012 17:51:09 +0000
To: Zefram via RT <bug-Module-Runtime [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
I've now reported the issue on Class::Load's RT queue, at <https://rt.cpan.org/Ticket/Display.html?id=74897>. -zefram
From: paul [...] city-fan.org
On Sun Feb 12 12:51:19 2012, zefram@fysh.org wrote: Show quoted text
> I've now reported the issue on Class::Load's RT queue, at > <https://rt.cpan.org/Ticket/Display.html?id=74897>. > > -zefram
Thanks for the analysis; Class-Load 0.17 has been pushed, which requires Module-Runtime 0.12 and fixes the problem.