Craig A. Berry <[EMAIL PROTECTED]> wrote:
> If you can reproduce the accvio in miniperl,
> the quickest way (without waiting all day to rebuild the entire thing
> in debug on your DEC 3000), would be to:
>
> $ mms/macro=__DEBUG__=1 dbgminiperl.exe
> $ mcr []dbgminiperl t/run/switches.t
>
> or of course just hack descrip.mms to give you a link/traceback.
> Once you know where in the C code the accvio occurs, you can rebuild
> that one module in debug, relink miniperl, and watch what's going on
> in the VMS debugger. You can always add one module at a time in a
> minute or two if you need others. This is the approach I use all the
> time on older machines where a complete debug build might take a
> couple of hours.
Thanks for the help so far, but of course miniperl didn't show this
behaviour :-( So I set up a second source tree and made a complete
debug version. Here's the stack trace:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=
0000000000000948, PC=000000000011531C, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
DBGPERLSHR UTIL Perl_safesysfree 49590 000000000000053C 000000000011531C
DBGPERLSHR VMS Perl_my_pclose 88026 000000000000A644 0000000000149694
DBGPERLSHR VMS pipe_exit_routine 86866 0000000000004CA0 0000000000143CF0
0 FFFFFFFF8006BBC4 FFFFFFFF8006BBC4
PTHREAD$RTL 0 000000000004636C 000000007BC1C36C
PTHREAD$RTL 0 00000000000312FC 000000007BC072FC
PTHREAD$RTL 0 0000000000021504 000000007BBF7504
0 0000000000000000 0000000000000000
PTHREAD$RTL ? ?
0 FFFFFFFF82CF9494 FFFFFFFF82CF9494
So I dug in the listings for these source lines.
UTIL.C:Perl_safesysfree:49590 :
DEBUG_m( PerlIO_printf(Perl_debug_log, "0x%"UVxf": (%05ld)
free\n",PTR2UV(where),(long)PL_an++));
Huh?
DEBUG_m is defined in perl.h as
STMT_START { \
if (PERL_GET_INTERP) { dTHX; if (DEBUG_m_TEST) {PL_debug&=~DEBUG_m_FLAG; a;
PL_debug|=DEBUG_m_FLAG;} } \
} STMT_END
Hmmm... funny that it should ACCVIO in a line that mostly doesn't get
executed without setting up memory debugging... So it seems like
STMT_START, dTHX, or STMT_END is the culprit, right?
Anyway, I ran the reproducer again with $^D set to ~0 right before the
$result = `$runperl` line. Don't know whther it's relevant, though. The
resulting output (including the ACCVIO) can be downloaded at
http://www.pdv-systeme.de/users/martinv/perl_accvio.zip
(as I wouldn't want to attach a 140k ZIP file to this message).
Next I'll make a build without ithreads and see if that behaves better.
And if so - I can live without threads (I think).
BTW: There's some quoting problem at the very end of the build process
when building with debug:
...
Copy/Log [.POD]PERLUTIL.POD [.LIB.POD]PERLUTIL.POD
%COPY-S-COPIED, USER_DISK:[USER.MV.PROJEKTE.PERL-5_8_0-DBG.POD]PERLUTIL.POD;1 co
pied to USER_DISK:[USER.MV.PROJEKTE.PERL-5_8_0-DBG.LIB.POD]PERLUTIL.POD;1 (13 bl
ocks)
%DCL-W-PARMDEL, invalid parameter delimiter - check use of special characters
\=1") test' to run test suite."\
%MMS-F-ABORT, For target ALL, CLI returned abort status: %X00038110.
I think it meant to say to run
MMS /MACRO=("DEBUG=1") test
and there wouldn't be any action following this, right?
cu,
Martin
--
One OS to rule them all | Martin Vorlaender | VMS & WNT programmer
One OS to find them | work: [EMAIL PROTECTED]
One OS to bring them all | http://www.pdv-systeme.de/users/martinv/
And in the Darkness bind them.| home: [EMAIL PROTECTED]
