Mailing List Archive

Steve Hay wrote on 2012-05-14:
> On 12 May 2012 13:55, kmx <kmx@atlas.cz> wrote:
>>
>>> It's a great shame that I've not been able to fix this. Is anyone
>>> else seeing this, or is it just me? I get the same thing on two
>>> different machines, so it's at least not just one particular machine.
>>
>> I see more or less the same failures and hanging tests on Win7/64bit
>> box with 32bit perl-5.16-RC0 build (by 32bit gcc 4.6.3 + C-runtime
>> from
>> mingw-w64.sf.net)
>>
>> However, on the same box (Win7/64bit) with 64bit build of the same
>> perl (by 64bit gcc 4.6.3 + C-runtime from mingw-w64.sf.net)
>> surprisingly *no tests
>> hang*
>>
>
> Interesting... However, I've just tried a 64-bit build using VC++ 2010
> and I still get tests hanging as before :-(


Trying out some more build options hasn't helped at all (debug builds hang just the same, and I see the same stack trace as Alex Gough reported; and builds without PERL_IMPLICIT_SYS also hang just the same), but unfortunately I've found another problem in the process :-(

It seems that win32/runenv.t fails tests 42-43 when perl is built with USE_IMP_SYS=undef (i.e. PERL_IMPLICIT_SYS is not defined, so there is no fork() emulation):

# Failed test 42 - expected number of elements in @INC for enough items so PERL5
LIB val is longer than 32k at win32/runenv.t line 246
# got "2"
# expected "2051"
# Failed test 43 - expected elements in @INC for enough items so PERL5LIB val is
longer than 32k at win32/runenv.t line 249
# got "D:/temp/bleadperl/t/lib ."
# expected "zzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzz
[...]
zzzzzzzzzz zzzzzzzzzzzzzzzz zzzzzzzzzzzzzzzz D:/temp/bleadperl/t/lib ."
ok 41 - No errors when determining @INC for enough items so PERL5LIB val is long
er than 32k
not ok 42 - expected number of elements in @INC for enough items so PERL5LIB val
is longer than 32k
not ok 43 - expected elements in @INC for enough items so PERL5LIB val is longer
than 32k
Failed 2/43 subtests

Test Summary Report
-------------------
win32/runenv.t (Wstat: 0 Tests: 43 Failed: 2)
Failed tests: 42-43
Files=1, Tests=43, 1 wallclock secs ( 0.03 usr + 0.00 sys = 0.03 CPU)
Result: FAIL

On Fri, May 11, 2012 at 10:10:08AM +0100, Steve Hay wrote:
> Ricardo Signes wrote on 2012-05-11:
> > I've just uploaded the first release candidate of Perl 5.16.0 to
> PAUSE.
> >
> > The files should be available soon, with the following SHA sums:
> >
> > 3f08f8e00adc215ccbf6aff38c58eef58f4df102 perl-5.16.0-RC0.tar.bz2
> > 99ce35a3e1a48b6936e3e2e56966cb6736181875 perl-5.16.0-RC0.tar.gz
>
> Default build out-of-the-box on Windows 7 x64 with VC++ 2010 SP1 is
> sadly not a pleasant experience for me. As reported previously, numerous
> tests hang and have to be killed, yielding the test results below. As
> noted before, however, all is well aside from the intermittent fork.t
> test 24 failure if STDERR is redirected somewhere.
>
> It's a great shame that I've not been able to fix this. Is anyone else
> seeing this, or is it just me? I get the same thing on two different
> machines, so it's at least not just one particular machine.

Another strangeness in the behaviour here:

nmake test

hangs in various Module-Build tests.

But:

nmake test TEST_FILES=..\cpan\Module-Build\t\*.t

runs the Module-Build tests without a problem.

nmake test TEST_FILES="base/*.t ../cpan/Module-Build/t/*.t"

hangs in perl_mb_opt.t, as does:

cd ../t
.\perl harness base/cond.t ../cpan/Module-Build/t/perl_mb_opt.t

Tony

Tony Cook wrote on 2012-05-24:
> On Fri, May 11, 2012 at 10:10:08AM +0100, Steve Hay wrote:
>> Ricardo Signes wrote on 2012-05-11:
>>> I've just uploaded the first release candidate of Perl 5.16.0 to
PAUSE.
>>>
>>> The files should be available soon, with the following SHA sums:
>>>
>>> 3f08f8e00adc215ccbf6aff38c58eef58f4df102 perl-5.16.0-RC0.tar.bz2
>>> 99ce35a3e1a48b6936e3e2e56966cb6736181875 perl-5.16.0-RC0.tar.gz
>>
>> Default build out-of-the-box on Windows 7 x64 with VC++ 2010 SP1 is
>> sadly not a pleasant experience for me. As reported previously,
>> numerous tests hang and have to be killed, yielding the test results
>> below. As noted before, however, all is well aside from the
>> intermittent fork.t test 24 failure if STDERR is redirected
somewhere.
>>
>> It's a great shame that I've not been able to fix this. Is anyone
else
>> seeing this, or is it just me? I get the same thing on two different
>> machines, so it's at least not just one particular machine.
>
> Another strangeness in the behaviour here:
>
> nmake test
> hangs in various Module-Build tests.
>
> But:
>
> nmake test TEST_FILES=..\cpan\Module-Build\t\*.t
> runs the Module-Build tests without a problem.

Yes, I found originally that the full test suite hangs (originally in
CPANPLUS tests and then again in Module-Build tests, but now seemingly
only in the latter), but when you try to look harder at individual hangs
then they don't hang any more :-(


>
> nmake test TEST_FILES="base/*.t ../cpan/Module-Build/t/*.t"
> hangs in perl_mb_opt.t, as does:
>
> cd ../t
> .\perl harness base/cond.t ../cpan/Module-Build/t/perl_mb_opt.t
> Tony

I can reproduce the same result with the nmake command, which is useful
to avoid having to run the *whole* test suite every time, but the perl
harness command you've given runs without hanging for me :-/

I currently get three hanging tests in Module-Build (I'm ignoring here
the fork.t script which still intermittently hangs too): runthrough.t,
test_types.t and xs.t, and they all have the same call stack when
breaking into them when hung:

[.Frames below may be incorrect and/or missing, no symbols loaded
for ntdll.dll]
ntdll.dll!779bf901()
mswsock.dll!74c06e67()
mswsock.dll!74bfe8d0()
mswsock.dll!74bf7d8c()
ws2_32.dll!754d5a7a()
ws2_32.dll!754d5fe8()
ws2_32.dll!754c394b()
> perl517.dll!my_close(int fd) Line 474 + 0xa bytes C
perl517.dll!win32_close(int fd) Line 3065 + 0x9 bytes C
perl517.dll!PerlLIOClose(IPerlLIO * piPerl, int handle) Line
948 + 0x9 bytes C++
perl517.dll!PerlIOUnix_close(interpreter * my_perl, _PerlIO * *
f) Line 2871 + 0x1c bytes C
perl517.dll!PerlIOBase_close(interpreter * my_perl, _PerlIO * *
f) Line 2216 + 0x10 bytes C
perl517.dll!PerlIOBuf_close(interpreter * my_perl, _PerlIO * *
f) Line 4235 + 0xd bytes C
perl517.dll!PerlIO__close(interpreter * my_perl, _PerlIO * * f)
Line 1474 + 0x10 bytes C
perl517.dll!Perl_PerlIO_close(interpreter * my_perl, _PerlIO * *
f) Line 1487 + 0xd bytes C
perl517.dll!Perl_do_openn(interpreter * my_perl, gv * gv, const
char * oname, long len, int as_raw, int rawmode, int rawperm, _PerlIO *
* supplied_fp, sv * * svp, long num_svs) Line 664 + 0xd bytes C
perl517.dll!Perl_pp_open(interpreter * my_perl) Line 625 + 0x2e
bytes C
perl517.dll!Perl_runops_debug(interpreter * my_perl) Line 2118
+ 0xf bytes C
perl517.dll!S_run_body(interpreter * my_perl, long oldscope)
Line 2397 + 0xf bytes C
perl517.dll!perl_run(interpreter * my_perl) Line 2320 + 0xd
bytes C
perl517.dll!RunPerl(int argc, char * * argv, char * * env) Line
270 + 0x9 bytes C++
perl.exe!main(int argc, char * * argv, char * * env) Line 23 +
0x12 bytes C
perl.exe!__tmainCRTStartup() Line 555 + 0x17 bytes C
kernel32.dll!7604339a()
ntdll.dll!779d9ef2()
ntdll.dll!779d9ec5()
ntdll.dll!779ce38c()