From: kutcha@eos.acm.rpi.edu (Phillip Rzewski)
Subject: sys$crmpsc crashing on me
Organization: The Voice of Fate
Date: Tue, 15 Dec 1992 03:20:58 GMT

    I've been working with a program under VMS that attempts to use shared
memory. I can't say I've done this before so when I found myself faced with an
ugly error I did what any red blooded programmer would do: I hacked at it for
about 3 hours and when I realized I was getting nowhere I decided to try and
find someone on Usenet who might have a clue.

    Basically it's a program from a book. The book uses all VAX Pascal code and
I am trying to convert it to VAX C and get it running. I think I have found out
exactly where the problem is, but I am having trouble finding out how to fix
it. First consider the Pascal bit (a lot of stuff has been deleted in order
to isolate things to just the troublesome code):

[inherit ('SYS$LIBRARY:STARLET',
           'SYS$LIBRARY:PASCAL$LIB_ROUTINES')]

PROGRAM SHARED_DATA (INPUT, OUTPUT);
VAR
  X: [VOLATILE, ALIGNED(9)] INTEGER;
  IN_ADDR: ARRAY [1..2] OF INTEGER;
  err : INTEGER;
BEGIN
  IN_ADDR[1] := IADDRESS (X);
  IN_ADDR[2] := IADDRESS (X) + 3;
  WRITELN (IN_ADDR[1]);
  WRITELN (IN_ADDR[2]);
  err := $CRMPSC (
              inadr := IN_ADDR,
              flags := SEC$M_GBL +
                       SEC$M_WRT +
                       SEC$M_PERM +
                       SEC$M_DZRO +
                       SEC$M_PAGFIL,
              gsdnam := 'SHARED_X',
              pagcnt := 1);
.
.
.

    And the program continues on from there. This particular stuff is right out
of the book, and thus it works. The author points out that X is declared as
"ALIGNED" so that way it is "declared to be on a page boundary". Before we go
into that, consider my C code:

#include <stdio.h>
#include <ssdef.h>
#include <secdef.h>
#include <starlet.h>
#include <descrip.h>
#include "[-]syscall.h"

#define GSDNAM "SHARED_X"

int main(void)
{
  unsigned long x;
  unsigned long in_addr[2];
  unsigned long ret_status;
  $DESCRIPTOR(gsdnam_dsc, GSDNAM);

  in_addr[0] = (unsigned long) &x;
  in_addr[1] = (unsigned long) (&x + 3);
  printf("%u\n", in_addr[0]);
  printf("%u\n", in_addr[1]);
  ret_status = sys$crmpsc(&in_addr, 0, 0, SEC$M_GBL + SEC$M_WRT + SEC$M_PERM +
          SEC$M_DZRO + SEC$M_PAGFIL, &gsdnam_dsc, 0, 0, 0, (unsigned long) 1,
          0, 0, 0);
.
.
.

    And the program continues on from there.

    The problem I am having with the C code is, as you can guess, in the
sys$crmpsc call. I was getting an evil stack dump, so I decided to compile
and link it in debug mode and run things in the debugger. When it got to the
sys$crmpsc call it would crash out with:

%DEBUG-E-INTERR, internal debugger error in DBGGSWATCH\unable to read mapping
arguments - 2

    I looked quite closely at all the parameters in the call, and it was
obvious that the only one I could be messing up was the in_addr one. I tried
all kinds of hacks (different combinations of ampersands and assigning
variables here and there) but nothing seemed to make it budge. Then I went back
to the Pascal code and put in those WRITELNs you see. I noticed that on the
Pascal side of things, the addresses were nice LITTLE numbers like "512", while
on the C side they were big and ugly like "2146263408".

    Something tells me that the value that IADDRESS is giving back on the
Pascal side is just the address of the data relative to the starting point of
the program. Meanwhile, on the C side of things, I am getting the "real"
address of the data in memory. Since the nice small Pascal numbers were what
made the call work, I figure that what I am looking for on the VAX C side is
something like IADDRESS that will give me the smaller memory addresses.  But I
don't know of anything that will do that. Can anyone help?

    Also (and I don't think this is related to what is making it crash) I am
puzzled by the "ALIGNED" business from the Pascal code. While I can understand
why one would want their data that way when working with pages of memory, I
don't know of any C keyword that does the equivalent of that. Anyone have an
idea on what to do about that? Should I just ignore it? (If I can get the first
part fixed, I'll gladly ignore it. :) )

--
  Phillip Andrew Rzewski                      Internet: kutcha@acm.rpi.edu
             "Don't wait; while you're waiting, you're dying."
                          --- Peter Hammill