30900 breaks MIME-tools
Andreas J. Koenig
loop today with blead@30900. Confirmed with 30902. 30898 had no
problem with it.
t/Entity............Use of uninitialized value within %INC in pattern match (m//
) at /home/src/perl/repoperls/installed-perls/perl/p7R8oCc/perl-5.8.0@30900/lib/
site_perl/5.9.5/Mail/Field.pm line 114.
Use of uninitialized value in concatenation (.) or string at /home/src/perl/repo
perls/installed-perls/perl/p7R8oCc/perl-5.8.0@30900/lib/site_perl/5.9.5/Mail/Fie
ld.pm line 114.
closedir() attempted on invalid dirhandle DIR at /home/src/perl/repoperls/instal
led-perls/perl/p7R8oCc/perl-5.8.0@30900/lib/site_perl/5.9.5/Mail/Field.pm line 9
1.
Warning: Use of "require" without parentheses is ambiguous at (eval 482) line 1.
Warning: Use of "require" without parentheses is ambiguous at (eval 483) line 1.
Warning: Use of "require" without parentheses is ambiguous at (eval 484) line 1.
Warning: Use of "require" without parentheses is ambiguous at (eval 485) line 1.
Warning: Use of "require" without parentheses is ambiguous at (eval 486) line 1.
[...]
closedir() attempted on invalid dirhandle DIR at /home/src/perl/repoperls/instal
led-perls/perl/p7R8oCc/perl-5.8.0@30900/lib/site_perl/5.9.5/Mail/Field.pm line 9
1.
[...]
closedir() attempted on invalid dirhandle DIR at /home/src/perl/repoperls/instal
led-perls/perl/p7R8oCc/perl-5.8.0@30900/lib/site_perl/5.9.5/Mail/Field.pm line 9
1.
closedir() attempted on invalid dirhandle DIR at /home/src/perl/repoperls/instal
led-perls/perl/p7R8oCc/perl-5.8.0@30900/lib/site_perl/5.9.5/Mail/Field.pm line 9
1.
closedir() attempted on invalid dirhandle DIR at /home/src/perl/repoperls/instal
led-perls/perl/p7R8oCc/perl-5.8.0@30900/lib/site_perl/5.9.5/Mail/Field.pm line 9
1.
Warning: Use of "require" without parentheses is ambiguous at (eval 740) line 1.
Bareword found where operator expected at (eval 740) line 1, near "200::lvchange
"
(Missing operator before ::lvchange?)
Warning: Use of "require" without parentheses is ambiguous at (eval 741) line 1.
Bareword found where operator expected at (eval 741) line 1, near "200::lvm"
(Missing operator before ::lvm?)
Warning: Use of "require" without parentheses is ambiguous at (eval 742) line 1.
Bareword found where operator expected at (eval 742) line 1, near "200::vgcfgres
tore"
(Missing operator before ::vgcfgrestore?)
Warning: Use of "require" without parentheses is ambiguous at (eval 743) line 1.
Bareword found where operator expected at (eval 743) line 1, near "200::lvcreate
"
(Missing operator before ::lvcreate?)
[...about 6 million lines of "closedir attempted" and "require without parentheses"...]
Warning: Use of "require" without parentheses is ambiguous at (eval 5936852) line 1.
Warning: Use of "require" without parentheses is ambiguous at (eval 5936853) line 1.
Warning: Use of "require" without parentheses is ambiguous at (eval 5936854) line 1.
Warning: Use of "require" without parentheses is ambiguous at (eval 5936855) line 1.
Warning: Use of "require" without parentheses is ambiguous at (eval 5936856) line 1.
Warning: Use of "require" without parentheses is ambiguous at (eval 5936857) line 1.
Warning: Use of "require" without parentheses is ambiguous at (eval 5936858) line 1.
--
andreas
Nicholas Clark
> 'make test' on DSKOLL/MIME-tools-5.420.tar.gz goes into a fast endless
> loop today with blead@30900. Confirmed with 30902. 30898 had no
> problem with it.
Are you sure about that?
I see this crazy looping as far back as 30000, from a clean build.
I'm not sure how much further to push it.
Nicholas Clark
Andreas J. Koenig
Nick, I just interviewed myself and tried to squeeze more facts out of
me but I cannot draw conclusions. Here are the tapes. Please follow up
with more questions.
* Nick denies 30900's responsibility. Something else must be it because
he sees the crazy loop going back to 30000. So I must gather facts now.
So please let me ask a few questions. -- Go ahead.
MIME-tools is a distribution, not a module. Which module represents
MIME-tools? -- MIME::Body
Which perls between 30000 and 30900 have MIME::Body installed
on your box? -- 30383, 30384, 30388, 30391, 30392, 30393,
30394, 30399, 30402, 30405, 30408, 30413, 30414, 30415, 30418,
30419, 30420, 30884, 30888, 30898
Do you have logfiles written for those versions? --
30383=>20070223T2127, 30384=>20070224T1000,
30388=>20070224T1500, 30391=>20070224T1957,
30392=>20070225T0045, 30393=>20070225T0524,
30394=>20070225T1622, 30399=>20070225T2121,
30402=>20070226T0344, 30405=>20070226T0904,
30408=>20070226T1412, 30413=>20070226T1902,
30414=>20070227T0414, 30415=>20070227T1355,
30418=>20070227T1856, 30419=>20070227T2342,
30420=>20070228T0417, 30884=>20070410T1050,
30888=>20070410T1614, 30898=>20070410T2143
The large gap after 30420 jumps into my eyes. What was the next logfile
after that? And for which patch? -- 20070228T1244 for 30428
And the last before 30844? -- 20070409T1809 for 30875
Did the tests in the succeeding runs really succeed on Entity.t or did
they probably skip it? -- All of above cited successful tests were
reported as "....ok" for Entity.t. All others complained "Can't locate
Mail/Internet.pm in @INC". I should point out that I had banned
Mail::Internet from being installed most of the time.
So which versions of MIME::Body and Mail::Internet did gain the cited
successes above? -- MIME::Body was always 5.42. For Mail::Internet it
was from 30383 up to 30420 the module version 1.74 and from 30884 up to
30898 it was 1.76.
Would you mind installing Mail::Internet and MIME::Body for 30428 and
report? -- For Mail::Internet CPAN.pm chose MARKOV/MailTools-1.76.tar.gz
to install and it succeeded. For MIME::Body it chose
DSKOLL/MIME-tools-5.420.tar.gz and it succeeded.
Would you do the same for 30875? -- I did it and got the same results.
Does 30915 still have the problem with the two modules? -- Yes.
--
andreas
Nicholas Clark
> me but I cannot draw conclusions. Here are the tapes. Please follow up
> with more questions.
What's your perl -V?
(I assume that all versions are built with the same Configure command line,
so just any one will probably say everything)
Nicholas Clark
Nicholas Clark
> >>>>> On Wed, 11 Apr 2007 11:55:39 +0100, Nicholas Clark <ni...@ccl4.org> said:
>
> > On Wed, Apr 11, 2007 at 08:45:27AM +0200, Andreas J. Koenig wrote:
> >> 'make test' on DSKOLL/MIME-tools-5.420.tar.gz goes into a fast endless
> >> loop today with blead@30900. Confirmed with 30902. 30898 had no
> >> problem with it.
>
> > Are you sure about that?
> > I see this crazy looping as far back as 30000, from a clean build.
> > I'm not sure how much further to push it.
>
> Nick, I just interviewed myself and tried to squeeze more facts out of
> me but I cannot draw conclusions. Here are the tapes. Please follow up
I'm confused too. Trying to work on how on earth one gets this:
Use of uninitialized value within %INC in pattern match (m//) at /home/nick/Sandpit/snap5.9.x-30915/lib/perl5/site_perl/5.9.5/Mail/Field.pm line 114.
Use of uninitialized value in concatenation (.) or string at /home/nick/Sandpit/snap5.9.x-30915/lib/perl5/site_perl/5.9.5/Mail/Field.pm line 114.
Line 114 is the middle of this:
my($f,$dir,$dir_sep);
foreach $f (keys %INC)
{
if($f =~ /^Mail(\W)Field\W/i)
{
$dir_sep = $1;
$dir = ($INC{$f} =~ /(.*Mail\W+Field)/i)[0] . $dir_sep;
last;
}
}
_require_dir('Mail::Field', $dir, $dir_sep);
How come $INC{$f} is undefined?
Nicholas Clark
Nicholas Clark
> I'm confused too. Trying to work on how on earth one gets this:
>
> Use of uninitialized value within %INC in pattern match (m//) at /home/nick/Sandpit/snap5.9.x-30915/lib/perl5/site_perl/5.9.5/Mail/Field.pm line 114.
> Use of uninitialized value in concatenation (.) or string at /home/nick/Sandpit/snap5.9.x-30915/lib/perl5/site_perl/5.9.5/Mail/Field.pm line 114.
This is key.
>
> Line 114 is the middle of this:
>
> my($f,$dir,$dir_sep);
> foreach $f (keys %INC)
> {
> if($f =~ /^Mail(\W)Field\W/i)
> {
> $dir_sep = $1;
> $dir = ($INC{$f} =~ /(.*Mail\W+Field)/i)[0] . $dir_sep;
> last;
> }
> }
> _require_dir('Mail::Field', $dir, $dir_sep);
>
>
> How come $INC{$f} is undefined?
(gdb) call Perl_hv_fetch(PL_incgv->sv_u.svu_gp->gp_hv, "Mail/Field/Date.pm", 18, 0)
$11 = (SV **) 0x84155d0
(gdb) call Perl_sv_dump( *(SV **) 0x84155d0 )
SV = NULL(0x0) at 0x828fbf8
REFCNT = 2147482861
FLAGS = (READONLY)
use Mail::Field 1.05 ();
from
use MIME::Head;
from
use MIME::Entity;
[note that that call would return NULL if the hash lookup failed]
So why is $INC{'Mail/Field/Date.pm'} undef?
My smallest testcase, from inside the MIME::Tools directory, is:
/home/nick/Sandpit/snap5.9.x-30915/bin/perl5.9.5 -w -Mblib -e 'use MIME::Head' 2>&1| less
(I'd advise the redirection and less to stop the near infinite spew)
If I move the contents of Head.pm into another file, there is no issue.
The near infinite spew of warnings is because Mail::Field is doing readdir
to traverse directories starting from the path in $INC, and is treating undef
as /
I need to go to bed now. Anyone else curious is welcome to play.
Nicholas Clark
Andreas J. Koenig
Yes, my config arguments are always the same.
% /home/src/perl/repoperls/installed-perls/*/p*/perl-5.8.0@30915/bin/perl -V
Summary of my perl5 (revision 5 version 9 subversion 5) configuration:
Platform:
osname=linux, osvers=2.6.18-4-k7, archname=i686-linux-64int
uname='linux k75 2.6.18-4-k7 #1 smp mon mar 26 17:57:15 utc 2007 i686 gnulinux '
config_args='-Dprefix=/home/src/perl/repoperls/installed-perls/perl/pvm7x7i/perl-5.8.0@30915 -Dinstallusrbinperl=n -Uversiononly -Doptimize=-g -des -Duse64bitint -Dusedevel'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-g',
cppflags='-DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='4.1.2 20061115 (prerelease) (Debian 4.1.1-21)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /usr/lib64
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.3.6.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.3.6'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -g -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO
Locally applied patches:
DEVEL
patchaperlup: --branch='perl' --upto='30915' --start='17639'
Built under linux
Compiled at Apr 11 2007 22:57:59
@INC:
/home/src/perl/repoperls/installed-perls/perl/pvm7x7i/perl-5.8.0@30915/lib/5.9.5/i686-linux-64int
/home/src/perl/repoperls/installed-perls/perl/pvm7x7i/perl-5.8.0@30915/lib/5.9.5
/home/src/perl/repoperls/installed-perls/perl/pvm7x7i/perl-5.8.0@30915/lib/site_perl/5.9.5/i686-linux-64int
/home/src/perl/repoperls/installed-perls/perl/pvm7x7i/perl-5.8.0@30915/lib/site_perl/5.9.5
.
--
andreas
Rick Delaney
>
> So why is $INC{'Mail/Field/Date.pm'} undef?
Because Mail::Field::Date didn't compile? Mail::Field does
C<eval "require ${pkg}::$p"> but doesn't deal with the failure case.
When require failures were treated as successes this would have resulted
in a defined %INC entry but now failures are cached in %INC as undef.
--
Rick Delaney
ri...@bort.ca
Andreas J. Koenig
Indeed. Mail::Field::Date doesn't compile because Date::Format is not
installed (it is not a declared prerequisite). When I install
Date::Format the bug goes away. Yay!
And I never discovered the bug because Date::Format usually is
installed early because many modules depend on it. I do install
modules in random order but it took some time until it happened that I
installed Mail-Tools and MIME-Tools before TimeDate.
But I still don't get it whose bug it is. Has bleadperl changed
treatment of %INC?
--
andreas
Nicholas Clark
On Thu, Apr 12, 2007 at 08:46:06AM +0200, Andreas J. Koenig wrote:
> >>>>> On Wed, 11 Apr 2007 23:33:06 -0400, Rick Delaney <ri...@bort.ca> said:
>
> installed (it is not a declared prerequisite). When I install
> Date::Format the bug goes away. Yay!
>
> And I never discovered the bug because Date::Format usually is
> installed early because many modules depend on it. I do install
> modules in random order but it took some time until it happened that I
> installed Mail-Tools and MIME-Tools before TimeDate.
>
> But I still don't get it whose bug it is. Has bleadperl changed
> treatment of %INC?
Yes. You read Rick's paragraph too quickly. It's in your quoted text :-)
Should we change the caching behaviour to use PL_sv_placeholder rather than
PL_sv_undef? That way you it won't be visible from perl space?
Alternatively, do we need to document this IN BIG LETTERS?
Nicholas Clark
Rick Delaney
>
> On Thu, Apr 12, 2007 at 08:46:06AM +0200, Andreas J. Koenig wrote:
> > >>>>> On Wed, 11 Apr 2007 23:33:06 -0400, Rick Delaney <ri...@bort.ca> said:
> > > When require failures were treated as successes this would have resulted
> > > in a defined %INC entry but now failures are cached in %INC as undef.
> > treatment of %INC?
>
> Yes. You read Rick's paragraph too quickly. It's in your quoted text :-)
>
> Should we change the caching behaviour to use PL_sv_placeholder rather than
> PL_sv_undef? That way you it won't be visible from perl space?
I tried this already which led to change 23843. Others didn't like this
which led to change 23873. Full discussion:
http://rt.perl.org/rt3/Public/Bug/Display.html?id=31924
To me, the biggest argument against this approach is that you wouldn't
be able to retry the require from Perl. With PL_sv_undef, it is just
delete $INC{$file};
require $file;
That works whether $file compiled or not the first time.
> Alternatively, do we need to document this IN BIG LETTERS?
I think this would be best.
--
Rick Delaney
ri...@bort.ca