Bleadperl v5.13.10-408-ged0d180 breaks AZAWAWI/Syntax-Highlight-Perl6-0.88.tar.gz #11241

p5pRT · 2011-04-06T20:08:43Z

Migrated from rt.perl.org#87940 (status was 'resolved')

Searchable as RT87940$

p5pRT · 2011-04-06T20:08:46Z

From @andk

git bisect:

ed0d180 is the first bad commit
commit ed0d180
Author: David Leadbeater <dgl@dgl.cx>
Date: Tue Mar 8 21:49:54 2011 +0000

Switch Storable to IO::File from FileHandle, only load if needed

On blead IO::File would be autoloaded but can't rely on this as
Storable is dual life.

example fail report:

http://www.cpantesters.org/cpan/report/1977fc20-600b-11e0-9f9d-81ac42987c1d

perl -V:

Summary of my perl5 (revision 5 version 13 subversion 10) configuration:
Commit id: ed0d180
Platform:
osname=linux, osvers=2.6.32-5-amd64, archname=x86_64-linux
uname='linux k81 2.6.32-5-amd64 #1 smp wed jan 12 03:40:32 utc 2011 x86_64 gnulinux '
config_args='-Dprefix=/home/src/perl/repoperls/installed-perls/perl/v5.13.10-408-ged0d180 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Uuselongdouble -DDEBUGGING=-g'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2 -g',
cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.5.2', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.11.2.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.11.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl):
Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
PERL_PRESERVE_IVUV PERL_USE_DEVEL USE_64_BIT_ALL
USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO
USE_PERL_ATOF
Built under linux
Compiled at Apr 6 2011 10:39:09
@INC:
/home/src/perl/repoperls/installed-perls/perl/v5.13.10-408-ged0d180/lib/site_perl/5.13.10/x86_64-linux
/home/src/perl/repoperls/installed-perls/perl/v5.13.10-408-ged0d180/lib/site_perl/5.13.10
/home/src/perl/repoperls/installed-perls/perl/v5.13.10-408-ged0d180/lib/5.13.10/x86_64-linux
/home/src/perl/repoperls/installed-perls/perl/v5.13.10-408-ged0d180/lib/5.13.10
.

--
andreas

p5pRT · 2011-04-06T21:35:39Z

From @dgl

On 6 Apr 2011, at 21:08, (Andreas J. Koenig) (via RT) wrote:

http://www.cpantesters.org/cpan/report/1977fc20-600b-11e0-9f9d-81ac42987c1d
[...]

Looks like it relied on loading Storable resulting in IO::File being loaded. This previously was the case but ed0d180 changed to a require as only file_magic needed it loaded.

(Syntax::Highlight::Perl6 doesn't directly load Storable; STD loads Storable via STD::Cursor then CursorBase).

David

p5pRT · 2011-04-06T21:35:39Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2011-04-07T08:53:29Z

From @dgl

On Wed, Apr 06, 2011 at 10:35:02PM +0100, David Leadbeater wrote:

Looks like it relied on loading Storable resulting in IO::File being
loaded. This previously was the case but ed0d180 changed to a
require as only file_magic needed it loaded.
[...]

However, that is not the whole story, there is another issue here as
the error in the CPAN testers report contains "usage:
IO::File->new()" which shouldn't be appearing.

It turns out loading IO::Handle is enough for IO::File's new method to
start existing due to the @ISA for this being setup in the core (see
S_init_predump_symbols in perl.c).

This means the feature added in 15e6cdd to automatically load
IO::File methods results in unpredictable behaviour if IO::Handle has
been loaded first (as it picks up IO::Handle's new method, rather than
IO::File's).

$ perl -MIO::Handle -e'IO::File->new("x")
usage: IO::File->new() at -e line 1
$ perl -e'IO::File->new("x")'
[no croak]

This feels like a blocker to me, as it makes the automatic IO::File
loading feature unreliable. (Even though the underlying issue
presumably existed previously, perl now claims to automatically load
IO::File but won't in all cases.)

David

p5pRT · 2011-04-09T10:01:26Z

From @dgl

On 7 Apr 2011, at 09:52, David Leadbeater wrote:
[...]

This feels like a blocker to me, as it makes the automatic IO::File
loading feature unreliable. (Even though the underlying issue
presumably existed previously, perl now claims to automatically load
IO::File but won't in all cases.)

One solution is to always load IO::File if IO::Handle is loaded. This therefore avoids the case where only IO::Handle but not IO::File is loaded even existing.

I'm not sure I *like* this as a solution (as it introduces a circular dep.), but it does seem to solve the problem. I wouldn't be surprised if there's some large caveat I'm missing though .

All tests pass with the attached patch.

p5pRT · 2011-04-09T10:01:26Z

From @dgl

0001-Require-IO-File-in-IO-Handle.patch

From 2c2288612c512c1351dcd4453bac830d8f3df828 Mon Sep 17 00:00:00 2001
From: David Leadbeater <dgl@dgl.cx>
Date: Fri, 8 Apr 2011 21:33:20 +0100
Subject: [PATCH] Require IO::File in IO::Handle

Since 15e6cdd IO::File has been loaded automatically. However this
automatic loading would not happen in all cases if IO::Handle was
loaded previously. This is due to the @ISA for IO::File being
initialised by the core (see the discussion in [perl #87940]).

By ensuring IO::File is loaded if IO::Handle is the indeterminate
state cannot occur.
---
 dist/IO/lib/IO/Handle.pm |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/dist/IO/lib/IO/Handle.pm b/dist/IO/lib/IO/Handle.pm
index f6974eb..a7431fa 100644
--- a/dist/IO/lib/IO/Handle.pm
+++ b/dist/IO/lib/IO/Handle.pm
@@ -265,10 +265,16 @@ use Symbol;
 use SelectSaver;
 use IO ();	# Load the XS module
 
+# Since perl will automatically require IO::File if needed, but also
+# initialises IO::File's @ISA as part of the core we must ensure
+# IO::File is loaded if IO::Handle is. This avoids effectively
+# "half-loading" IO::File.
+require IO::File;
+
 require Exporter;
 @ISA = qw(Exporter);
 
-$VERSION = "1.30";
+$VERSION = "1.31";
 $VERSION = eval $VERSION;
 
 @EXPORT_OK = qw(
-- 
1.7.4.2

p5pRT · 2011-04-11T01:28:30Z

From @cpansprout

On Sat Apr 09 03:01:26 2011, dgl wrote:

On 7 Apr 2011, at 09:52, David Leadbeater wrote:
[...]

This feels like a blocker to me, as it makes the automatic IO::File
loading feature unreliable. (Even though the underlying issue
presumably existed previously, perl now claims to automatically load
IO::File but won't in all cases.)

One solution is to always load IO::File if IO::Handle is loaded. This
therefore avoids the case where only IO::Handle but not IO::File is
loaded even existing.

I'm not sure I *like* this as a solution

Although I don’t particularly like this solution either, the only other
ideas I have are more fragile fixes that would require a lot of testing.

(as it introduces a circular
dep.),

Circular dependencies between modules in the same distribution are fine.

but it does seem to solve the problem. I wouldn't be surprised
if there's some large caveat I'm missing though .

Not that I can think of.

So I have just applied your patch as efc5c7c. Thank you.

p5pRT · 2011-04-11T01:28:31Z

@cpansprout - Status changed from 'open' to 'resolved'

p5pRT · 2011-04-14T13:26:35Z

From @cpansprout

On Sun Apr 10 18:28:30 2011, sprout wrote:

On Sat Apr 09 03:01:26 2011, dgl wrote:

On 7 Apr 2011, at 09:52, David Leadbeater wrote:
[...]

This feels like a blocker to me, as it makes the automatic IO::File
loading feature unreliable. (Even though the underlying issue
presumably existed previously, perl now claims to automatically load
IO::File but won't in all cases.)

One solution is to always load IO::File if IO::Handle is loaded. This
therefore avoids the case where only IO::Handle but not IO::File is
loaded even existing.

I'm not sure I *like* this as a solution

Although I don’t particularly like this solution either, the only other
ideas I have are more fragile fixes that would require a lot of testing.

(as it introduces a circular
dep.),

Circular dependencies between modules in the same distribution are fine.

Famous last words.

It works for pure-OO modules, but importing/exporting can complicate things.

See: http://perl5.git.perl.org/perl.git/commitdiff/221e5db

but it does seem to solve the problem. I wouldn't be surprised
if there's some large caveat I'm missing though .

Not that I can think of.

So I have just applied your patch as efc5c7c. Thank you.

p5pRT closed this as completed Apr 11, 2011

p5pRT added Severity Low distro-Linux labels Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bleadperl v5.13.10-408-ged0d180 breaks AZAWAWI/Syntax-Highlight-Perl6-0.88.tar.gz #11241

Bleadperl v5.13.10-408-ged0d180 breaks AZAWAWI/Syntax-Highlight-Perl6-0.88.tar.gz #11241

p5pRT commented Apr 6, 2011

p5pRT commented Apr 6, 2011

p5pRT commented Apr 6, 2011

p5pRT commented Apr 6, 2011

p5pRT commented Apr 7, 2011

p5pRT commented Apr 9, 2011

p5pRT commented Apr 9, 2011

p5pRT commented Apr 11, 2011

p5pRT commented Apr 11, 2011

p5pRT commented Apr 14, 2011

Bleadperl v5.13.10-408-ged0d180 breaks AZAWAWI/Syntax-Highlight-Perl6-0.88.tar.gz #11241

Bleadperl v5.13.10-408-ged0d180 breaks AZAWAWI/Syntax-Highlight-Perl6-0.88.tar.gz #11241

Comments

p5pRT commented Apr 6, 2011

p5pRT commented Apr 6, 2011

From @andk

p5pRT commented Apr 6, 2011

From @dgl

p5pRT commented Apr 6, 2011

p5pRT commented Apr 7, 2011

From @dgl

p5pRT commented Apr 9, 2011

From @dgl

p5pRT commented Apr 9, 2011

From @dgl

p5pRT commented Apr 11, 2011

From @cpansprout

p5pRT commented Apr 11, 2011

p5pRT commented Apr 14, 2011

From @cpansprout