From @wchristian

Created by @wchristian

The 1.96 release of CPAN has a bug that breaks installation processes on Win32 when YAML​::XS is present.

Related ticket​: https://rt.cpan.org/Public/Bug/Display.html?id=65105
Related patch​: andk/cpanpm#16

The github version of CPAN.pm is already fixed, but this fix should also go into core as soon as possible.

Short explanation​: CPAN.pm gets a read-exclusive lock on ftp_stats.yml and later tries to read that file while the lock still exists. If this read attempt is done through YAML​::XS the process will be unable to get by the read lock and abort.

Flags:
     category=library
     severity=high
     module=CPAN

Site configuration information for perl 5.10.1:

Configured by SYSTEM at Tue Jan 26 23:14:33 2010.

Summary of my perl5 (revision 5 version 10 subversion 1) configuration:

   Platform:
     osname=MSWin32, osvers=5.00, archname=MSWin32-x86-multi-thread
     uname=''
     config_args='undef'
     hint=recommended, useposix=true, d_sigaction=undef
     useithreads=define, usemultiplicity=define
     useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
     use64bitint=undef, use64bitall=undef, uselongdouble=undef
     usemymalloc=n, bincompat5005=undef
   Compiler:
     cc='C:/MinGW/bin/gcc.exe', ccflags ='-DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -DHASATTRIBUTE -fno-strict-aliasing -mms-bitfields',
     optimize='-O2',
     cppflags='-DWIN32'
     ccversion='', gccversion='4.5.2', gccosandvers=''
     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
     d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8
     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8
     alignbytes=8, prototype=define
   Linker and Libraries:
     ld='C:\MinGW\bin\g++.exe', ldflags ='-L"C:\Perl\lib\CORE"'
     libpth=\lib
     libs=-lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lmsvcrt
     perllibs=-lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -lmsvcrt
     libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl510.lib
     gnulibc_version=''
   Dynamic Linking:
     dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
     cccdlflags=' ', lddlflags='-mdll -L"C:\Perl\lib\CORE"'

Locally applied patches:
     ACTIVEPERL_LOCAL_PATCHES_ENTRY
     0abd0d disable non-unicode case insensitive trie matching


@INC for perl 5.10.1:
     C:/Perl/site/lib
     C:/Perl/lib
     .


Environment for perl 5.10.1:
     CYGWIN=nodosfilewarning
     HOME=c:\Dokumente und Einstellungen\Administrator
     LANG (unset)
     LANGUAGE (unset)
     LD_LIBRARY_PATH (unset)
     LOGDIR (unset)
     PATH=C:\Programme\PC Connectivity Solution\;C:\Programme\ActiveState Komodo IDE 6;C:\Programme\NVIDIA Corporation\PhysX\Common;C:\wamp\bin\php\php5.3.0\;C:\Programme\ImageMagick-6.6.7-Q16;C:\Perl\bin;C:\Perl\site\bin;C:\Programme\CollabNet Subversion Server\;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\Programme\Gemeinsame Dateien\Lenovo;C:\Programme\Microsoft SQL Server\90\Tools\binn\;C:\Programme\WinSCP\;C:\Programme\VDMSound;C:\Programme\Subversion;C:\Programme\QuickTime\QTSystem\;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\Programme\Intel\WiFi\bin\;c:\Programme\PostgreSQL\8.4\bin\;C:\Programme\TortoiseSVN\bin;C:\Programme\Git\cmd;c:\MinGW\dmake\;C:\MinGW\bin\;C:\blast\bin;C:\Programme\OpenVPN\bin;c:\Sysinternals;c:\Programme\MySQL\MySQL Server 5.1\bin\;C:\cygwin\bin;C:\Programme\Graphviz2.26.3\bin;C:\Programme\TortoiseGit\bin
     PERL_BADLANG (unset)
     SHELL (unset)

From @obra

On Tue 26.Apr'11 at 12​:18​:57 -0700, Christian Walde wrote​:

The 1.96 release of CPAN has a bug that breaks installation processes on Win32 when YAML​::XS is present.

Related ticket​: https://rt.cpan.org/Public/Bug/Display.html?id=65105
Related patch​: andk/cpanpm#16

The github version of CPAN.pm is already fixed, but this fix should also go into core as soon as possible.

Short explanation​: CPAN.pm gets a read-exclusive lock on ftp_stats.yml and later tries to read that file while the lock still exists. If this read attempt is done through YAML​::XS the process will be unable to get by the read lock and abort.

If it's an activeperl-specific issue, I'd expect that this would be
something you should be reporting to ActiveState, not p5p.

Jesse

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

From @jandubois

On Wed, 27 Apr 2011, Jesse Vincent wrote​:

On Tue 26.Apr'11 at 12​:18​:57 -0700, Christian Walde wrote​:

The 1.96 release of CPAN has a bug that breaks installation
processes on Win32 when YAML​::XS is present.

Related ticket​: https://rt.cpan.org/Public/Bug/Display.html?id=65105
Related patch​: andk/cpanpm#16

The github version of CPAN.pm is already fixed, but this fix should
also go into core as soon as possible.

Short explanation​: CPAN.pm gets a read-exclusive lock on
ftp_stats.yml and later tries to read that file while the lock still
exists. If this read attempt is done through YAML​::XS the process
will be unable to get by the read lock and abort.

If it's an activeperl-specific issue, I'd expect that this would be
something you should be reporting to ActiveState, not p5p.

The change actually comes *from* ActivePerl. It is my fault that I
didn't report it back to Andreas ages ago. It is not ActivePerl
specific; it affects all Perl builds on Windows once you install
YAML​::XS *and* tell CPAN.pm that it should use YAML​::XS as its
YAML backend.

This is not a regression; the issue has existed for a long time and
it also easy to work around​: tell CPAN.pm that you don't have a YAML
module installed, and it will just work fine. YAML is only used to
store some cache information.

Cheers,
-Jan

From @xdg

On Wed, Apr 27, 2011 at 9​:31 PM, Jan Dubois <jand@​activestate.com> wrote​:

The change actually comes *from* ActivePerl. It is my fault that I
didn't report it back to Andreas ages ago. It is not ActivePerl
specific; it affects all Perl builds on Windows once you install
YAML​::XS *and* tell CPAN.pm that it should use YAML​::XS as its
YAML backend.

This is not a regression; the issue has existed for a long time and
it also easy to work around​: tell CPAN.pm that you don't have a YAML
module installed, and it will just work fine.  YAML is only used to
store some cache information.

It's not a regression and my understanding is that the fix in CPAN.pm
has already been applied to the CPAN.pm repo. That needs to be
released and then we can debate whether this is an issue for 5.16 or
worth backporting to 5.14.1 Possibly, ActiveState might want to
backport it separately into a 5.14.1 release, even if the Perl core
doesn't apply it to 5.14.1.

-- David

From @csjewell

On Wed, 27 Apr 2011 23​:13 -0400, "David Golden" <xdaveg@​gmail.com>
wrote​:

On Wed, Apr 27, 2011 at 9​:31 PM, Jan Dubois <jand@​activestate.com> wrote​:

The change actually comes *from* ActivePerl. It is my fault that I
didn't report it back to Andreas ages ago. It is not ActivePerl
specific; it affects all Perl builds on Windows once you install
YAML​::XS *and* tell CPAN.pm that it should use YAML​::XS as its
YAML backend.

This is not a regression; the issue has existed for a long time and
it also easy to work around​: tell CPAN.pm that you don't have a YAML
module installed, and it will just work fine.  YAML is only used to
store some cache information.

It's not a regression and my understanding is that the fix in CPAN.pm
has already been applied to the CPAN.pm repo. That needs to be
released and then we can debate whether this is an issue for 5.16 or
worth backporting to 5.14.1 Possibly, ActiveState might want to
backport it separately into a 5.14.1 release, even if the Perl core
doesn't apply it to 5.14.1.

-- David

And I'll make sure this is in the Strawberry Perl build process for the
5.14.0/5.12.4 release.

(this sounds like it solves a weird bug I was having when I turned on
YAML​::XS for an experiment in the pre-5.12.0 days.)

[and yes, I am working on Strawberry again now in my copious spare time.
*grin* Gonna try and get the major bug that's in the 5.12.2 build fixed
before I do a 5.14.0, and as many others as I can.]

--Curtis
--
Curtis Jewell
csjewell@​cpan.org http​://csjewell.dreamwidth.org/
perl@​csjewell.fastmail.us http​://csjewell.comyr.org/perl/

"Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

Strawberry Perl for Windows betas​: http​://strawberryperl.com/beta/

From @jandubois

On Wed, 27 Apr 2011, David Golden wrote​:

On Wed, Apr 27, 2011 at 9​:31 PM, Jan Dubois <jand@​activestate.com> wrote​:

The change actually comes *from* ActivePerl. It is my fault that I
  ^^^^^^
didn't report it back to Andreas ages ago.

It's not a regression and my understanding is that the fix in CPAN.pm
has already been applied to the CPAN.pm repo. That needs to be
released and then we can debate whether this is an issue for 5.16 or
worth backporting to 5.14.1 Possibly, ActiveState might want to
backport it separately into a 5.14.1 release, even if the Perl core
doesn't apply it to 5.14.1.

Don't worry about ActivePerl; that change has been in every ActivePerl
release since June 2008... As I wrote above, I should have reported
it back much earlier. Christian just did this recently, after I pointed
him at the diff file between ActivePerl and the core release.

Cheers,
-Jan

From vadim.konovalov@alcatel-lucent.com

From​: Curtis Jewell
On Wed, 27 Apr 2011 23​:13 -0400, "David Golden" wrote​:

It's not a regression and my understanding is that the fix in CPAN.pm
has already been applied to the CPAN.pm repo. That needs to be
released and then we can debate whether this is an issue for 5.16 or
worth backporting to 5.14.1 Possibly, ActiveState might want to
backport it separately into a 5.14.1 release, even if the Perl core
doesn't apply it to 5.14.1.

And I'll make sure this is in the Strawberry Perl build
process for the
5.14.0/5.12.4 release.

kewl.

so this patch (affecting win32) will be in all 5.14.0 binariy distributions,
but will absent in 5.14.0 sources?

someone will claim that perl developers are intentionally tricking their minds
by having binaries and source do not match.

BTW has anyone understood why 'make test' hangs several times during
testing some 'cpan' tests?
These are not related?

Vadim.

From mmaslano@redhat.com

On 04/28/2011 09​:38 AM, Konovalov, Vadim (Vadim)** CTR ** wrote​:

From​: Curtis Jewell
On Wed, 27 Apr 2011 23​:13 -0400, "David Golden" wrote​:

It's not a regression and my understanding is that the fix in CPAN.pm
has already been applied to the CPAN.pm repo. That needs to be
released and then we can debate whether this is an issue for 5.16 or
worth backporting to 5.14.1 Possibly, ActiveState might want to
backport it separately into a 5.14.1 release, even if the Perl core
doesn't apply it to 5.14.1.

And I'll make sure this is in the Strawberry Perl build
process for the
5.14.0/5.12.4 release.

kewl.

so this patch (affecting win32) will be in all 5.14.0 binariy distributions,
but will absent in 5.14.0 sources?

someone will claim that perl developers are intentionally tricking their minds
by having binaries and source do not match.

I suppose upstream is only trying to release stable release without
nasty surprises.

BTW has anyone understood why 'make test' hangs several times during
testing some 'cpan' tests?
These are not related?

Vadim.

I had problems with tests, which required packages outside of perl tar
ball. If they are detected, they are used, but because they weren't
rebuild with 5.14, they failed to work. All tests should pass if you
have clean paths.

Regards,
--
Marcela Mašlá�ová
BaseOS team Brno

From @wchristian

On Thu, 28 Apr 2011 09​:38​:06 +0200, Konovalov, Vadim (Vadim)** CTR **
<vadim.konovalov@​alcatel-lucent.com> wrote​:

so this patch (affecting win32) will be in all 5.14.0 binariy
distributions,
but will absent in 5.14.0 sources?

Right now ActiveState is fixing this (and other things) in their
packaged releases. I suspect Strawberry is doing the same.

That is not a very good situation to be in, but started in the past due
to p5p being rather slow. Now that there is a steady release schedule
things can be integrated reliably and this is why this ticket was made.

--
With regards,
Christian Walde

From @xdg

On Thu, Apr 28, 2011 at 3​:38 AM, Konovalov, Vadim (Vadim)** CTR **
<vadim.konovalov@​alcatel-lucent.com> wrote​:

so this patch (affecting win32) will be in all 5.14.0 binariy distributions,
but will absent in 5.14.0 sources?

someone will claim that perl developers are intentionally tricking their minds
by having binaries and source do not match.

Perl "developers" do not release binaries, only source.

Perl "distributors" -- which would include ActivePerl, Strawberry, as
well as many OS distributions that include a binary package for Perl
-- already often make local modifications. Run 'perl -V' and look for
the section "Locally applied patches". For example, my stock 5.10.1
on Ubuntu 10.10 lists 40 patches by the Debian team.

So, this is really nothing new.

-- David

From vadim.konovalov@alcatel-lucent.com

From​: David Golden
On Thu, Apr 28, 2011 at 3​:38 AM, Konovalov, Vadim wrote​:

so this patch (affecting win32) will be in all 5.14.0
binariy distributions,
but will absent in 5.14.0 sources?

someone will claim that perl developers are intentionally
tricking their minds
by having binaries and source do not match.

Perl "developers" do not release binaries, only source.

Perl "distributors" -- which would include ActivePerl, Strawberry, as
well as many OS distributions that include a binary package for Perl
-- already often make local modifications. Run 'perl -V' and look for
the section "Locally applied patches". For example, my stock 5.10.1
on Ubuntu 10.10 lists 40 patches by the Debian team.

I know how this predictable divergence appears.

IMO, this "frozen" state - is too frozen.
It would be better if some bug fixes come through this freeze.

At least - I would be more than happy if some t/cpan/* hangs on win32
would be identified and fixed.

But this is of course not for me to decide :)

So, this is really nothing new.

Yes, not a regression :)

Vadim.

From @Leont

On Thu, Apr 28, 2011 at 2​:42 PM, Konovalov, Vadim (Vadim)** CTR **
<vadim.konovalov@​alcatel-lucent.com> wrote​:

I know how this predictable divergence appears.

IMO, this "frozen" state - is too frozen.
It would be better if some bug fixes come through this freeze.

Bleed has only been this frozen for a little more than a week. Before
that there was 3 weeks of almost frozen in which this probably would
have been acceptable. Before that blead was open as usual. If we delay
releasing it every time a useful patch is submitted we won't be
releasing until christmas!

Leon

From vadim.konovalov@alcatel-lucent.com

From​: Leon Timmermans
On Thu, Apr 28, 2011 at 2​:42 PM, Konovalov, Vadim wrote​:

IMO, this "frozen" state - is too frozen.
It would be better if some bug fixes come through this freeze.

Bleed has only been this frozen for a little more than a week. Before
that there was 3 weeks of almost frozen in which this probably would
have been acceptable. Before that blead was open as usual. If we delay
releasing it every time a useful patch is submitted we won't be
releasing until christmas!

I am not speaking about useful patch,

cygwin and win32 users report hangs during test,
this is more of a problem, IMHO.

Regards,
Vadim.

From vadim.konovalov@alcatel-lucent.com

From​: Konovalov, Vadim

From​: Leon Timmermans
On Thu, Apr 28, 2011 at 2​:42 PM, Konovalov, Vadim wrote​:

IMO, this "frozen" state - is too frozen.
It would be better if some bug fixes come through this freeze.

Bleed has only been this frozen for a little more than a
week. Before
that there was 3 weeks of almost frozen in which this probably would
have been acceptable. Before that blead was open as usual.
If we delay
releasing it every time a useful patch is submitted we won't be
releasing until christmas!

I am not speaking about useful patch,

cygwin and win32 users report hangs during test,
this is more of a problem, IMHO.

sorry for mixing apples and oranges,
this threads was talking about another problem,

it was not intentional that I spoke about different problem.

Sorry.
Vadim.

From @jandubois

On Thu, 28 Apr 2011, Konovalov, Vadim (Vadim)** CTR ** wrote​:

At least - I would be more than happy if some t/cpan/* hangs on win32
would be identified and fixed.

As I wrote before, the *only* time I could get the Perl tests to hang on
Windows was when Cygwin/bin/ was on the PATH. I suspect that
Archive​::Extract is calling some Cygwin extraction tool or something
like that. Removing the Cygwin directory and running `nmake test` again
always fixed things for me.

But this is of course not for me to decide :)

No, but you are very welcome to narrow down the problem beyond "it
hangs". :) Ideally you would create a patch, but at the very least you
could file a bug report that says "It hangs because of ...".

If this is not a priority for you, why should it be a priority
for anyone else?

Cheers,
-Jan

From @greerga

On Thu, 28 Apr 2011, Konovalov, Vadim (Vadim)** CTR ** wrote​:

From​: Leon Timmermans
On Thu, Apr 28, 2011 at 2​:42 PM, Konovalov, Vadim wrote​:

IMO, this "frozen" state - is too frozen.
It would be better if some bug fixes come through this freeze.

Bleed has only been this frozen for a little more than a week. Before
that there was 3 weeks of almost frozen in which this probably would
have been acceptable. Before that blead was open as usual. If we delay
releasing it every time a useful patch is submitted we won't be
releasing until christmas!

I am not speaking about useful patch,

cygwin and win32 users report hangs during test,
this is more of a problem, IMHO.

What Win32? Mine on Windows 2000 with MSVC 2005 has no hiccups for a long
time.

--
George Greer

From vadim.konovalov@alcatel-lucent.com

From​: Jan Dubois
On Thu, 28 Apr 2011, Konovalov, Vadim (Vadim)** CTR ** wrote​:

At least - I would be more than happy if some t/cpan/*
hangs on win32
would be identified and fixed.

As I wrote before, the *only* time I could get the Perl tests
to hang on
Windows was when Cygwin/bin/ was on the PATH. I suspect that
Archive​::Extract is calling some Cygwin extraction tool or something
like that. Removing the Cygwin directory and running `nmake
test` again
always fixed things for me.

removing cygwin from PATH does not help in my case.

But this is of course not for me to decide :)

No, but you are very welcome to narrow down the problem beyond "it
hangs". :) Ideally you would create a patch, but at the very least you
could file a bug report that says "It hangs because of ...".

All true.
Fortunately the problem is recognized and - I believe - will be fixed.
If not - I will have a deeper look.

Regards,
Vadim.

From @jkeenan

I reviewed this older ticket today.

Comments in related ticket
https://rt.cpan.org/Ticket/Display.html?id=65105 suggest that the issue
has been resolved there, but since that ticket was never closed I posted
a request that it be closed.

Discussion in *this* ticket appears to have diverged from the OP's
complaint. Is there any reason why *this* ticket needs to be kept open?

Thank you very much.
Jim Keenan

From @doy

The problem in this ticket has been resolved. If there are other
problems, they should be reported separately.

-doy

From [Unknown Contact. See original ticket]

The problem in this ticket has been resolved. If there are other
problems, they should be reported separately.

-doy

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