With HP C V7.1-015 on OpenVMS Alpha V8.3, -Duseithreads, I get

Failed 4 tests out of 1080, 99.63% okay.
        [-.lib.ExtUtils.t]cd.t
        [-.lib.ExtUtils.t]eu_command.t
        [-.lib.ExtUtils.t]xs.t
        op/threads.t

Fixes are available for cd.t and xs.t; since these are test patches
only and will not affect what gets installed, is it kosher to just
patch them and not take on the risk of a full-scale integration?

eu_command.t does not fail when run by itself and I haven't figured
out what it's tripping over (possibly a temp file left by some other
test that gets cleaned up later).

op/threads.t also fails on 5.8.8 (not the version that shipped with
it, but the new version of the test fails when run on 5.8.8).  The test
that fails is labeled:

[perl #45053] Memory corruption with heavy module loading in threads

and it may well be that our dynamic loading code is a bit lacking in
the thread safety department.  The crash is below.  If this is the
only thing holding up 5.8.9, I think we should document it as a known
problem and move on.

# Failed at [.op]threads.t line 133
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000A4CB7C, PC=FFFFFFFF802118A4, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs PC
                                            0 FFFFFFFF802118A4 FFFFFFFF802118A4
 DBGPERLSHR  DL_VMS  findsym_handler    91967 0000000000000CD4 00000000000B2CD4
 DECC$SHR_EV56                              0 000000000002F48C FFFFFFFF80EC748C
----- above condition handler called with exception 001582FA:
%LIB-E-KEYNOTFOU, key not found in tree
----- end of exception message
                                            0 FFFFFFFF800AD11C FFFFFFFF800AD11C
 LIBRTL                                     0 000000000008E074 FFFFFFFF80CBE074
 DBGPERLSHR  DL_VMS  my_find_image_symbol
                                        91982 000000000000101C 00000000000B301C
 DBGPERLSHR  DL_VMS  XS_DynaLoader_dl_load_file
                                        92164 0000000000004080 00000000000B6080
 DBGPERLSHR  PP_HOT  Perl_pp_entersub   66430 000000000000CDA4 00000000001BDFE4
 DBGPERLSHR  DUMP  Perl_runops_debug    68850 0000000000006FD4 0000000000186F24
 DBGPERLSHR  PERL  S_call_body          66524 0000000000005698 00000000000BE798
 DBGPERLSHR  PERL  Perl_call_sv         66452 000000000000543C 00000000000BE53C
 PL_THREADS  THREADS  S_ithread_run     67198 000000000000187C 000000000043787C
 PTHREAD$RTL                                0 000000000005763C FFFFFFFF80E7763C
 PTHREAD$RTL                                0 00000000000437A0 FFFFFFFF80E637A0
                                            0 0000000000000000 0000000000000000
 PTHREAD$RTL                                                 ?                ?
                                            0 FFFFFFFF8037BCE4 FFFFFFFF8037BCE4
%TRACE-I-END, end of TRACE stack dump
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

Reply via email to