|
HP OpenVMS Systemsask the wizard |
|
The Question is:
Recenttly I wrote TCP/IP server program in C, It is running like what I
would expect. Then I had to convert it to Fortan. But it shows some weird
behaviour. In both program, execution flow and logic even subroutine`s name
are same.
Program is like this
MAIN
CALL SETUP_SERVER
--Set up TCP/IP server by QIO system serv.
CALL CONNECTACCEPT
--When new connection request comes, fires
an AST routine,ACCEPTAST.
--In ACCEPTAST, que a read request from
the newly connected channel by QIO and
AST which is READAST. Then
CALL CONNECTACCEPT again to que another
connection accept.
--In READAST,when data comes, do something
with the data and CALL READDATA to que
another read request from client.
CALL SYS$HIBER
END
STOP
Now in READAST it reads data from the client,
and then sends modified data to the client. Then
When it calls READDATA again to que another read
request program crashes. I don't understand why
it works in C version but not in FORTRAN. I also
did write with same logic a DECnet server in FORTRAN, it runs perfectly. I
used AST rouitenes several times before. The error message is following:
%SYSTEM-F-OPCDEC, opcode reserved to DIGITAL fault at PC=00000512,
PSL=03C00000
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
00000512
00000512
80287955
80287955
SERVER SERVER 2692 00000039
00004E39
At the line 2692, I have CALL SYS$HIBER
Thanks in advance for your consideration.
The Answer is :
>%SYSTEM-F-OPCDEC, opcode reserved to DIGITAL fault at PC=00000512,
>PSL=03C00000
>%TRACE-F-TRACEBACK, symbolic stack dump follows
>module name routine name line rel PC abs PC
>
> 00000512 00000512
> 80287955 80287955
>SERVER SERVER 2692 00000039 00004E39
>
>At the line 2692, I have CALL SYS$HIBER
It's not a lot to go on, but the OpenVMS Wizard will extract as much as
possible from it...
The OPCDEC error means you've executed a bad instruction at address
512. Since there is no routine name or module name, this suggests the
address is outside any valid routines.
Since line 2692 calls SYS$HIBER, we would expect to see on the stack,
the call frame for SERVER calling SYS$HIBER (which we do at abs PC 4E39)
and for SYS$HIBER being interrupted by the AST dispatch routine (address
80287955), Then your AST routine. Instead we're seeing the (apparently)
invalid address 512. This suggests the possibility that your READDATA
routine is corrupting the return address to READAST in the call frame.
When READDATA exits, your program jumps to junk instructions somewhere
around address 512, resulting in the OPCDEC fault.
To find this type of error, run your server program under DEBUG control
and SET BREAK READDATA. Step through the routine and use the
SHOW STACK 1 command to examine the call frame. It should look
something like this:
DBG> SHOW STACK 1
stack frame 0 (2146353936)
condition handler: 0
SPA: 0
S: 1
mask: ^M<R11>
PSW: 0020 (hexadecimal)
saved AP: 2146353984
saved FP: 2146353964
saved PC: READAST\%LINE 4
saved R11: 1032
Note the saved PC points back to READAST. Each time you STEP through
a line, check the stack again and make sure nothing has changed.
One other possibility is that one of your routines has declared the
AST address incorrectly (perhaps the $QIO in READDATA?). Check all
your arguments carefully, specifically check the ASTADR argument in all
places it is used. In FORTRAN it is critical that the name used as
the ASTADR be declared EXTERNAL. For example:
SUBROUTINE READDATA(CHAN)
IMPLICIT NONE
EXTERNAL READAST,IO$_READVBLK
INTEGER*2 CHAN
...
STATUS=SYS$QIO(,%VAL(CHAN),IO$_READVBLK,IOSB,READAST,ASTPRM,
1 %REF(BUFFER),%VAL(BUFFSIZE),,,,)
...
END
A missing EXTERNAL statement would certainly result in an OPCDEC (or
similar) error. The OpenVMS Wizard suspects the latter explanation
is the most likely.
Also see topic 1661 for discussions of synchronization issues.
|