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
