At 11:52 AM +0000 3/6/08, Nicholas Clark wrote: >On Wed, Mar 05, 2008 at 08:11:59PM -0600, Craig A. Berry wrote: >> At 11:52 PM +0000 3/5/08, Nicholas Clark wrote: >> >I've made another 5.8.x snapshot. >> > >> >http://www.ccl4.org/~nick/P/perl-33444.tar.bz2 >> >(or http://www.ccl4.org/~nick/P/perl-33444.tar.gz ) >> > >> >It's closing in on what 5.8.9 is going to be, give or take breakage, late >> >interesting bug fixes, and resolution of some things that aren't quite there >> >yet >> > >> >Aside from -Dodgy.pm on VOS, what is still broken that wasn't broken in >> >5.8.8? >> >> At 33430 (always just a bit behind you) on VMS I see: >> >> t/op/threads................................FAILED--expected 10 tests, saw 9 >> ext/threads/shared/t/stress.................FAILED at test 1 >> ext/threads/t/blocks........................FAILED--expected 5 tests, saw 4 >> lib/ExtUtils/t/cd...........................FAILED at test 1 >> lib/ExtUtils/t/eu_command...................FAILED at test 21 > > lib/ExtUtils/t/xs...........................FAILED--non-zero wait status: > > 1024 >> Failed 6 tests out of 1080, 99.44% okay. >> >> Obviously that's a threaded build. The threads failures are access > > violations; I'll check whether 33436 does us any good there.
It doesn't. > >Did these fail that way on 5.8.8? The only failing test scripts that even existed in 5.8.8 were t/op/threads.t and lib/ExtUtils/t/xs.t. Both do a great deal more now than they did then. >I'd be surprised if anything that changed recently changed threaded behaviour. It appears to be something about global destruction under threads. If I take blocks.t and run it under 5.8.8, I get: $ perl d0:[craig.perl-5_8.ext.threads.t]blocks.t 1..5 Attempt to free unreferenced scalar: SV 0x579b28, Perl interpreter: 0x570370 at d0:[craig.perl-5_8.ext.threads.t]blocks.t line 91 during global destruction. ok 1 - Loaded Attempt to free unreferenced scalar: SV 0x5bcbe0, Perl interpreter: 0x570370 at d0:[craig.perl-5_8.ext.threads.t]blocks.t line 91 during global destruction. ok 2 - Main thread ok 3 - BEGIN thread ok 4 - Main join Attempt to free unreferenced scalar: SV 0x819cd8, Perl interpreter: 0x803820 at d0:[craig.perl-5_8.ext.threads.t]blocks.t line 91 during global destruction. ok 5 - BEGIN join but under [EMAIL PROTECTED] I get: $ perl [-.ext.threads.t]blocks.t 1..5 ok 1 - Loaded ok 2 - Main thread ok 3 - BEGIN thread ok 4 - Main join %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000014, PC=00000000001641D4, PS=0000001B %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine line rel PC abs PC DBGPERLSHR VMS Perl_flex_fstat 114875 000000000001C0D4 00000000001641D4 DBGPERLSHR VMS Perl_my_flush 113516 0000000000019AE8 0000000000161BE8 DBGPERLSHR PERLIO PerlIOStdio_flush 74500 0000000000007F24 00000000000CD524 DBGPERLSHR PERLIO Perl_PerlIO_flush 72872 0000000000003B2C 00000000000C912C DBGPERLSHR PERLIO Perl_PerlIO_flush 72896 0000000000003BD0 00000000000C91D0 DBGPERLSHR UTIL Perl_my_fflush_all 67339 0000000000005B94 000000000011DDD4 DBGPERLSHR PERL perl_destruct 64424 0000000000000DF4 00000000000B9EF4 PL_THREADS THREADS S_ithread_clear 66939 0000000000000344 00000000004C8344 PL_THREADS THREADS XS_threads_join 67973 0000000000006998 00000000004CE998 DBGPERLSHR PP_HOT Perl_pp_entersub 66441 000000000000CDA4 00000000001BDE94 DBGPERLSHR DUMP Perl_runops_debug 68864 0000000000007034 0000000000186DD4 DBGPERLSHR PERL S_run_body 66189 00000000000046D4 00000000000BD7D4 DBGPERLSHR PERL perl_run 66104 0000000000004300 00000000000BD400 NDBGPERL PERLMAIN main 63706 00000000000001FC 00000000000201FC NDBGPERL PERLMAIN __main 63650 00000000000000A0 00000000000200A0 PTHREAD$RTL 0 0000000000057618 FFFFFFFF80E77618 PTHREAD$RTL 0 0000000000030444 FFFFFFFF80E50444 0 FFFFFFFF80377CE4 FFFFFFFF80377CE4 %TRACE-I-END, end of TRACE stack dump The line where it blows up in the VMS-specific Perl_flex_fstat looks like so with its macro expansion under it: 3 114875 if (VMSISH_TIME) { E ((my_perl->Tcurcop)->op_private & ((0x80000000) >> 24)) Tcurcop has already been zeroed: DBG> examine my_perl->Tcurcop VMS\Perl_flex_fstat\my_perl->Tcurcop: 0 Something like the following safety check may do the trick. I'll try it out and see what happens. --- vms/vmsish.h;-0 Wed Mar 5 21:52:48 2008 +++ vms/vmsish.h Thu Mar 6 11:00:14 2008 @@ -296,7 +296,7 @@ #define HINT_M_VMSISH_TIME 0x80000000 /* times are local, not UTC */ #define NATIVE_HINTS (PL_hints >> HINT_V_VMSISH) /* used in op.c */ -#define TEST_VMSISH(h) (PL_curcop->op_private & ((h) >> HINT_V_VMSISH)) +#define TEST_VMSISH(h) (PL_curcop && (PL_curcop->op_private & ((h) >> HINT_V_VMSISH))) #define VMSISH_STATUS TEST_VMSISH(HINT_M_VMSISH_STATUS) #define VMSISH_TIME TEST_VMSISH(HINT_M_VMSISH_TIME) [end] > > For the MakeMaker failures, eu_command.t and xs.t behaved after >> upgrading to 6.43_01. cd.t I just patched last night: >> >> https://rt.cpan.org/Ticket/Display.html?id=33813 >> >> If there are no further integrations of MakeMaker in the cards (I >> think 6.44 is out), I can mark tests as TODO or otherwise patch the >> tests if you wish. > >I'm not sure what to do here. >Is MakeMaker in blead passing everywhere? >There are still patches outstanding in ExtUtils::Install, aren't there? Not sure how to advise you on this. I'm not aware of anything that worked under 5.8.8 that is not working now, but the tests are more extensive now. Sorry to be the spoilsport but these remaining items don't seem gigantic. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser