Pascal Compiler vs CMS Callable Routines

[rodprince]

Our build utilities are written in Pascal and make use of the CMS callable routines. When we execute a cms$set_library() followed by a cms$fetch(), we encounter an access violation when we exit the routine that made those two calls. The interesting part is the file in question is actually fetched out of the library. Its just the exit from the procedure is a little rough.

The CMS library was restored to the x86 system using a backup save set with /verify. The library in question has also been verified on the x86 system with a $cms/verify as well.

This code does work on IA64 HPE Pascal I64 V6.1-123 on OpenVMS I64 V8.4, using CMS V4.7-00. I have no ability to test it on a VSI IA64 system.

On the x86 system, we are using the following: Pascal x86-64 X6.3-138 (50X6f) on OpenVMS x86-64 V9.2-1 & VSI X86VMS CMS V4.8-9.

I have stripped the code down to as simple as I can make it. One routine with a cms$set_library() and cms$fetch() call. The cms library is hardcoded as cmsrootdev:[source.build] and the file is called build.vot. I would assume any cms library and file will cause the error.

Rod

Code: Select all

program build (input, output);

type
  varying_string  = varying [132] of char;
  cms_ldb_type    = array [1..50] of integer;


[asynchronous, external]
function cms$set_library ( %ref   lib_db : cms_ldb_type;
                           %descr libdir : varying [n] of char
                          ): integer; external;

[asynchronous, external]
function cms$fetch( %ref   ldb         : cms_ldb_type;
                    %descr element     : varying [i] of char;
                    %descr remark      : varying [j] of char;
                    %descr generation  : varying [k] of char;
                    %descr merge_gen   : varying [l] of char;
                    %ref   reserve     : integer := %immed 0;
                    %ref   nohistory   : integer := %immed 0;
                    %ref   nonotes     : integer := %immed 0;
                    %ref   concurrent  : integer := %immed 0;
                    %descr output_file : varying [m] of char
                  ) : integer; external;

type
  user_enviroment_def = record
    cms_class     : varying_string;
    cms_library   : varying_string;
    end;

var
  user_envir    : user_enviroment_def;



procedure get_file ;

const
  file_name = 'BUILD.VOT';

var
  vms_status : integer;
  cms_ldb    : cms_ldb_type;

begin
  vms_status := cms$set_library(cms_ldb,
                                user_envir.cms_library );

  if odd( vms_status) then
    cms$fetch( cms_ldb,
               file_name,
               %immed 0,               (* no remark *)
               user_envir.cms_class,
               %immed 0,               (* no merge generation *)
               %immed 0,               (* no reservation *)
               %immed 0,               (* no history *)
               %immed 0,               (* no notes *)
               %immed 0,               (* no concurrent *)
               file_name );

  if not odd(vms_status) then
    writeln( vms_status:1 );
end;


begin
  user_envir.cms_class   := '';
  user_envir.cms_library := 'CMSROOTDEV:[SOURCE.CMS]';
  
  get_file;
end.

[hb]

There is very likely a stack dump, probably no traceback, does it look like this?

Code: Select all

#include <stdio.h>
#include <descrip.h>

int main() {
        int lib_db[50];
        $DESCRIPTOR(d_lib, "CMS$LIB");
        int status = cms$set_library (lib_db, &d_lib);
        printf ("set_library, status %08x\n", status);
        $DESCRIPTOR(d_elem, "FILE.TXT");
        $DESCRIPTOR(d_gen, "");
        status = cms$fetch(lib_db, &d_elem, 0, &d_gen,
                   0, 0, 0, 0, 0, &d_elem );
        printf ("fetch, status %08x\n", status);
        return status;
}
$ r x
%CMS-I-LIBIS, library is SYS$COMMON:[SYSMGR.CMS.DEMO]
set_library, status 009c8421
%CMS-I-FILEXISTS, file already exists, SYS$SYSROOT:[SYSMGR]FILE.TXT;3 created
%CMS-S-FETCHED, generation 2 of element SYS$COMMON:[SYSMGR.CMS.DEMO]FILE.TXT fetched
fetch, status 009c8299
%SYSTEM-F-ACCVIO, access violation, reason mask=14, virtual address=0000000000000000, PC=0000000000000000, PS=0000001B

  Improperly handled condition, image exit forced by last chance handler.
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
                                 0000000000000014
                                 0000000000000000
                                 0000000000000000
                                 000000000000001B
    Register dump:
    RAX = 00000000009C8299  RDI = 000000007B782008  RSI = 0000000000000017
    RDX = 0000000000000000  RCX = 00000000009C8299  R8  = 0000000000059C80
    R9  = 0000000000000000  RBX = 000000007AC7FF00  RBP = 0000000000000000
    R10 = FFFFFFFFFFFFFFFE  R11 = 0000000000000001  R12 = 000000007AC7F9A8
    R13 = 0000000000000000  R14 = 0000000000000003  R15 = 0000000044C34606
    RIP = 0000000000000000  RSP = 000000007AC7F910  SS  = 000000000000001B
$

So a) this seems unrelated to Pascal and b) the IP aka PC is zero - as is the RBP, which is the frame pointer and that should be greater than the RSP, the stack pointer - how much depends on how much is on the stack of the current routine. Looks like a stack corruption to me: the RBP was saved on the stack and zero was restored.

[jreagan]

Well, at first, I was going to start looking at the CLASS_VS descriptors created by Pascal (which is the only "odd" thing about Pascal in the example). However, since hb showed that he go an ACCVIO with that C example, it now feels like a CMS issue. A ticket at the support portal is the best way to report this but I'll also point the CMS person to this post.