Pascal -x0604-144-1

[rodprince]

Interesting little crash this morning. Was trying to debug a pascal program that had throw an access violation. While talking to a colleague on the phone, I was single stepping into the routine that called the routine that threw the access violation and the debugger threw an info message. I commented to my colleague, that can't be good. As I as trying to step into the routine that actually threw the access violation, the debugger kind of went sideways and it all went down hill after that.

So I kind of have 2 issues. The first is the access violation, that points back to assigning A := B where A & B are varying [132] of char. The second issue is the debugger going south.

The version of code we are currently testing is the same code base that we started our OpenVMS x86 testing with. This routine has worked fine in all previous versions of the x86 pascal compiler excluding v0603-143. We were unable to compile the system with (v0603-143) due to compiler crash's, that have been resolved with x604-144-1.

I am going to concentrate on trying to reproduce the access violation and hope the debugger issue is due to all the warnings (Invalid tag) that the compiler threw while we were building the system.

Details for the system:

Code: Select all

------------------------------------ ----------- ----------- --- -----------
PRODUCT                              KIT TYPE    OPERATION   VAL DATE
------------------------------------ ----------- ----------- --- -----------
VSI X86VMS VMS922X_UPDATE V2.0       Patch       Install     Val 30-MAY-2024
VSI X86VMS CMS V4.8-9                Full LP     Install     Val 27-MAR-2024
VSI X86VMS DECSET V13.0-1            Platform    Install     Val 27-MAR-2024
VSI X86VMS DTM V4.5-6                Full LP     Install     Val 27-MAR-2024
VSI X86VMS ENVMGR V1.9-5             Full LP     Install     Val 27-MAR-2024
VSI X86VMS MMS V4.0-4                Full LP     Install     Val 27-MAR-2024
VSI X86VMS CXX A10.1-240307          Full LP     Install     Val 27-MAR-2024
VSI X86VMS C V7.5-9                  Full LP     Install     Val 27-MAR-2024
VSI X86VMS TCPIP V6.0-24             Full LP     Install     Val 27-MAR-2024
VSI X86VMS TCPIP V6.0-23             Full LP     Remove       -  27-MAR-2024
VSI X86VMS VMS922X_UPDATE V1.0       Patch       Install     Val 27-MAR-2024
VSI X86VMS VMS922X_PCSI V1.0         Patch       Install     Val 27-MAR-2024
VMSPORTS X86VMS PERL534 T5.34-0      Full LP     Install     Val 27-MAR-2024
VSI X86VMS AVAIL_MAN_BASE V9.2-2     Full LP     Install     Val 27-MAR-2024
VSI X86VMS DECNET_PHASE_IV V9.2-2    Full LP     Install     Val 27-MAR-2024
VSI X86VMS DWMOTIF V1.8              Full LP     Install     Val 27-MAR-2024
VSI X86VMS DWMOTIF_SUPPORT V9.2-2    Full LP     Install     Val 27-MAR-2024
VSI X86VMS KERBEROS V3.3-2A          Full LP     Install     Val 27-MAR-2024
VSI X86VMS OPENSSH V8.9-1G           Full LP     Install     Val 27-MAR-2024
VSI X86VMS OPENVMS V9.2-2            Platform    Install     Sys 27-MAR-2024
VSI X86VMS SSL111 V1.1-1W            Full LP     Install     Val 27-MAR-2024
VSI X86VMS SSL3 V3.0-11              Full LP     Install     Val 27-MAR-2024
VSI X86VMS TCPIP V6.0-23             Full LP     Install     Val 27-MAR-2024
VSI X86VMS VMS V9.2-2                Oper System Install     Val 27-MAR-2024
------------------------------------ ----------- ----------- --- -----------

The debugger sequence follows:

Code: Select all

DBG> step/into
%DEBUG-I-EXPMEMPOOL, expanding debugger memory pool
DBG> step/into
%DEBUG-F-ACCVIO, access violation, reason mask=04, virtual address=FFFFFFFF805C8538, PC=000000007B89D653, PS=0000001B

Logging enabled to file: DBGERR.LOG

If you wish to log a Debug problem report please include:

     o This file.
     o The operating system version number.
     o The system type or types if using Client/Server mode.
     o The program being debugged, both source and image.
     o The last, if not all, debug commands entered.
     o Any other information which you think would be helpful.
%DEBUG-I-EXPMEMPOOL, expanding debugger memory pool


Debugger Version: OpenVMS x86-64 Debug64 Version V9.2-009

image     module    routine               line      rel PC           abs PC
DEBUGSHR  X86_INSTRUCTION_VECTORS.C;1  dbg$compare_inst_tramp_plt
                                         #8342 0000000080025653 000000007B89D653
DEBUGSHR  DBGEVENT.B32;1  DECISION_EVENT_LINE
                                         #9009 00000000800E88B4 000000007B9608B4
DEBUGSHR  DBGEVENT.B32;1  DBG$PROCESS_EVENT
                                        #10520 00000000800EB5B0 000000007B9635B0
DEBUGSHR  DBGEVENT.B32;1  PROCESS_TRIGGER_LIST
                                         #3502 00000000800F637F 000000007B96E37F
DEBUGSHR  DBGEVENT.B32;1  DBG$EVENT_HANDLER
                                         #3837 00000000800CB7DC 000000007B9437DC
                                             0 FFFF8300079CE444 FFFF8300079CE444
LIBRTL  $1$DGA7217:[LIBRTL_4.SRC]LIBCALLG.MAR;1
                                          #181 00000000800EA7E9 FFFF8300099377E9
DEBUGSHR  DBGMRPC.B32;1  DBG$ACCEPT_CALL_MAIN_RPC
                                         #4526 00000000800BF911 000000007B937911
DEBUGSHR  DBGMAIN.B32;1  DBG$PROCESS_WORK_LIST
                                         #2250 000000008009FD73 000000007B917D73
DEBUGSHR  DBGMAIN.B32;1  DBG$ACTUAL_MAIN_LOOP
                                         #1796 000000008009F1E9 000000007B9171E9
DEBUGSHR  DBGMAIN.B32;1  DBG$MAIN_LOOP
                                         #1641 000000008009F14F 000000007B91714F
                                             0 FFFF8300081FC2E6 FFFF8300081FC2E6
DCL                                          0 000000008006799B 000000007ADFB99B
%TRACE-I-LINENUMBER, Leading '#' specifies a source file record number.

Due to this internal error this debug session may be unreliable.

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=8000000000000000, PC=FFFF830009A4B0BC, PS=0000001B
break on unhandled exception at SHARE$LIBOTS_CODE2+188
%DEBUG-I-SOURCESCOPE, source lines not available for %PC in scope number 0
        Displaying source for 1\%PC
  5051:       input := out;
DBG>

Added in 35 minutes 27 seconds:
Simple program to reproduce the %SYSTEM-F-ACCVIO that caused all the excitement for me today.

Code: Select all

program test(input, output);

type
  string_def = varying [132] of char;

procedure no_accvio(     input: string_def;
                     var out  : string_def );
begin
  out   := "will work";
  input := out;
end;

procedure accvio (     input: string_def;
                   var out  : string_def );
begin
  out   := "Accvio if out length > input string length";
  input := out;
end;

var
  t_in  : string_Def;
  t_out : string_def;

begin
  t_in := "INPUT__STRING__";

  no_accvio( t_in, t_out);
  writeln( 'no_accvio=', t_out );

  accvio( t_in, t_out );
  writeln( 'accvio=', t_out );
end.

compile & link and boom

Code: Select all

$pas test
$link test
$r test
no_accvio=will work
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000000
000C, PC=000000007B7FD506, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image     module    routine               line      rel PC           abs PC
PAS$RTL                                      0 0000000080027506 000000007B7FD506
PAS$RTL                                      0 0000000080015384 000000007B7EB384
PAS$RTL                                      0 000000008001B0DE 000000007B7F10DE
TEST  TEST  TEST                            31 00000000000000BE 00000000800000BE
                                             0 FFFF8300081FC2E6 FFFF8300081FC2E6
DCL                                          0 000000008006799B 000000007ADFB99B
%TRACE-I-END, end of TRACE stack dump

[arne_v]

I believe the debugger on VMS x86-64 9.x still needs a bit of work.



Added in 5 minutes 46 seconds:
Regarding the Pascal problem, then it seems to be a bug as it works fine on VMS Alpha Pascal 6.2, but assigning to a non-var argument is not nice code and may be why it was not tested.

[rodprince]

The "actual" code is doing work inside a loop. As its making a loop pass, its "altering" the input in different ways. Eventually it gets done and output ends up going back to the caller. The test case reproducer was just stripped down to show the accvio in as simple/basic code as possible. My guess, someone back in the Vax 11/730 days, thought, oh, I can save a couple of bytes of stack space and just use the same variable, no reason to need more memory.

To get around the issue, I declared a local variable of the same size as input should be, and using that for now. My only concern is, where else in the 1,600+ pascal files that are used to build the system did someone else decide, oh this is really good logic, let me copy it.

Rod

[jreagan]

Just back from holiday, I'll have somebody look at this.