Skip Menu |
 

This queue is for tickets about the Scalar-List-Utils CPAN distribution.

Report information
The Basics
Id: 100863
Status: resolved
Priority: 0/
Queue: Scalar-List-Utils

People
Owner: Nobody in particular
Requestors: leonerd-cpan [...] leonerd.org.uk
Cc:
AdminCc:

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



Subject: Sub::Util can successfully load but not provide set_subname
Download (untitled) / with headers
text/plain 796b
(migrated from https://github.com/Scalar-List-Utils/Scalar-List-Utils/issues/19 ) In Mojolicious we have a conditional use of set_subname. It checks that it can load Sub::Util and if it can it uses set_subname (see: https://github.com/kraih/mojo/blob/bf763eb87c6942cf7854d2a740636f567055d380/lib/Mojo/Util.pm#L31). The weird thing is that we are having errors occasionally where it tries to call the function and yet it isn't there, like so: http://www.cpantesters.org/cpan/report/209dfd02-8068-11e4-bdf9-8eb141983e00 . I have had it happen to me a couple times, and while we haven't tracked it down exactly, the suspicion is that the wrong XS file gets loaded. In all cases 'cpanm --reinstall Sub::Util' fixes it and Mojolicious is using a safer idiom now, we just thought we should report it.
On 2014-12-11 09:34:19, PEVANS wrote: Show quoted text
> (migrated from https://github.com/Scalar-List-Utils/Scalar-List- > Utils/issues/19 ) > > In Mojolicious we have a conditional use of set_subname. It checks > that it can load Sub::Util and if it can it uses set_subname (see: > https://github.com/kraih/mojo/blob/bf763eb87c6942cf7854d2a740636f567055d380/lib/Mojo/Util.pm#L31). > The weird thing is that we are having errors occasionally where it > tries to call the function and yet it isn't there, like so: > http://www.cpantesters.org/cpan/report/209dfd02-8068-11e4-bdf9- > 8eb141983e00 . I have had it happen to me a couple times, and while we > haven't tracked it down exactly, the suspicion is that the wrong XS > file gets loaded. > > In all cases 'cpanm --reinstall Sub::Util' fixes it and Mojolicious is > using a safer idiom now, we just thought we should report it.
I don't think it's enough to check for Sub::Util -- you should also check that its version is new enough: if (eval { require Sub::Util; Sub::Util->VERSION('1.40'); 1 }) { ... )
Download (untitled) / with headers
text/plain 1.2k
Possibly related: http://www.cpantesters.org/cpan/report/146c643c-8f0a-11e4-b9e9-1ef263ffe912 On Fri Dec 12 15:37:13 2014, ETHER wrote: Show quoted text
> On 2014-12-11 09:34:19, PEVANS wrote:
> > (migrated from https://github.com/Scalar-List-Utils/Scalar-List- > > Utils/issues/19 ) > > > > In Mojolicious we have a conditional use of set_subname. It checks > > that it can load Sub::Util and if it can it uses set_subname (see: > > https://github.com/kraih/mojo/blob/bf763eb87c6942cf7854d2a740636f567055d380/lib/Mojo/Util.pm#L31). > > The weird thing is that we are having errors occasionally where it > > tries to call the function and yet it isn't there, like so: > > http://www.cpantesters.org/cpan/report/209dfd02-8068-11e4-bdf9- > > 8eb141983e00 . I have had it happen to me a couple times, and while > > we > > haven't tracked it down exactly, the suspicion is that the wrong XS > > file gets loaded. > > > > In all cases 'cpanm --reinstall Sub::Util' fixes it and Mojolicious > > is > > using a safer idiom now, we just thought we should report it.
> > > I don't think it's enough to check for Sub::Util -- you should also > check that its version is new enough: > > if (eval { require Sub::Util; Sub::Util->VERSION('1.40'); 1 }) { ... )
Download (untitled) / with headers
text/plain 671b
Further chat on #p5p/Freenode today suggests an explaination to this: If there are multiple possible copies of List/Util.pm and .so available in @INC then it's possible that an older copy is found first. use Sub::Util; then skips over those older locations that don't have a Sub/Util.pm and find a later copy that does, which then internally has require List::Util; which now finds the *first*, older copy of List/Util.pm which pulls in its own older copy of List/Util.so. That file does not have the Sub::Util:: functions in it. I believe this behaviour could at least be detected by the attached patch and lead to more obvious error messages. -- Paul Evans
Subject: rt100863.patch
Download rt100863.patch
text/x-diff 1.1k
diff --git a/lib/Scalar/Util.pm b/lib/Scalar/Util.pm index 3f17d13..f270e32 100644 --- a/lib/Scalar/Util.pm +++ b/lib/Scalar/Util.pm @@ -8,7 +8,6 @@ package Scalar::Util; use strict; require Exporter; -require List::Util; # List::Util loads the XS our @ISA = qw(Exporter); our @EXPORT_OK = qw( @@ -20,6 +19,9 @@ our @EXPORT_OK = qw( our $VERSION = "1.41"; $VERSION = eval $VERSION; +require List::Util; # List::Util loads the XS +List::Util->VERSION( $VERSION ); # Ensure we got the right XS version (RT#100863) + our @EXPORT_FAIL; unless (defined &weaken) { diff --git a/lib/Sub/Util.pm b/lib/Sub/Util.pm index e40cf22..8c3b0f0 100644 --- a/lib/Sub/Util.pm +++ b/lib/Sub/Util.pm @@ -8,7 +8,6 @@ use strict; use warnings; require Exporter; -require List::Util; # as it has the XS our @ISA = qw( Exporter ); our @EXPORT_OK = qw( @@ -19,6 +18,9 @@ our @EXPORT_OK = qw( our $VERSION = "1.41"; $VERSION = eval $VERSION; +require List::Util; # as it has the XS +List::Util->VERSION( $VERSION ); # Ensure we got the right XS version (RT#100863) + =head1 NAME Sub::Util - A selection of utility subroutines for subs and CODE references
Released in 1.42 -- Paul Evans
Le 2015-04-01 17:36:47, PEVANS a écrit :
Show quoted text
> Further chat on #p5p/Freenode today suggests an explaination to this:
>
> If there are multiple possible copies of List/Util.pm and .so
> available in @INC then it's possible that an older copy is found
> first.

Here is a command helpful to diagnose this issue:

perl -MList::Util -MSub::Util=subname -E 'say "perl $^V"; say for @INC; say "Sub::Util $Sub::Util::VERSION"; say $INC{"Sub/Util.pm"}; say "List::Util $List::Util::VERSION"; say $INC{"List/Util.pm"}; say subname(\&subname)'

This is a toolchain issue, so the real fix would be to require an upgraded toolchain (I'm still trying to figure out which part, see RT#100863).

-- 
Olivier Mengué - http://perlresume.org/DOLMEN


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

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.