Debug printout, Fortran

[Kjell Carlsson]

A run time error in a fortran program results in the following print out:
%DEBUGBOOT-W-PROTINSTALL, protected images must be installed
%SYSTEM-F-INTDIV, arithmetic trap, integer divide by zero at PC=0000000000010091
, PS=0000001B

and then the dump info. No reference to source. What image is missing?

Integrity, OpenVMS 8.2-1, FORTRAN V8.1-1, VMS821I_DEBUG V3.0.

Regards
Kjell

[Hein van den Heuvel · Accepted solution]

Kjell,

Please consider to possibility that the error code returned is completely bogus.
Possibly the result of returning a function status into a float instead of an integer.
What is returned in DCL's $status?

The reported PC is also bogus.

This specific error would 'normally' only happen when starting an images (run, or call to lib$find_image_symbol). Is that what you are trying to do?

Did it ever work? What changed?

Good luck!
Hein.

[Kjell Carlsson]

Hein

The reported DCL status is
$STATUS == "%X10000484"

The program is just a sample which performs an integer divide by zero. The problem is that the debugger doesn't work correctly. This is for all .exe in this specific computer. It has never worked.

//kjell

[Robert Gezelter]

Kjell,

Before going too far, has somebody trimmed the list of installed images on this system??

- Bob Gezelter, http://www.rlgsc.com

[Hein van den Heuvel]

Ah! you are forcing the error in a reproducer.
That status is of course indeed a the INTDIV

probably a problem with sys$libary:SYS$SSISHR.EXE

Try with SET WATCH FILE/CLA=MAJOR ! Need CMKRL?

Missing debug image? SSISHR?
When I run a process with debugger I see:

[VMS$COMMON.SYSLIB]CMA$TIS_SHR.EXE;1 (section file)
[VMS$COMMON.SYSLIB]LIBRTL.EXE;1 (section file)
[VMS$COMMON.SYSLIB]SYS$SSISHR.EXE;1 (section file)
[VMS$COMMON.SYSLIB]DEBUG.EXE;1 (section file)
[VMS$COMMON.SYSMSG]DECC$MSG.EXE;1 (section file)
[VMS$COMMON.SYSMSG]SHRIMGMSG.EXE;1 (section file)
[VMS$COMMON.SYSMSG]DBGTBKMSG.EXE;1


$ pipe install list | search sys$pipe CMA,SSISHR,DEBUG
CMA$LIB_SHR;1
CMA$OPEN_LIB_SHR;1
CMA$OPEN_RTL;1 Open Hdr SharAddr Lnkbl Resid
CMA$RTL;1 Open Hdr SharAddr Lnkbl Resid
CMA$TIS_SHR;1 Open Hdr SharAddr Lnkbl Resid
DEBUG;1 Open Hdr Shared Lnkbl
DEBUGSHR;1 Open Hdr SharAddr Lnkbl
DEBUGUISHR;1 Open Hdr Shared Lnkbl
SYS$SSISHR;1 Open Hdr Shared Prot Lnkbl

[Hein van den Heuvel]

I now see you are running 8.2
That was just a 'starter' version.
Pretty good, but you really want to be at 8.3, which has been there for a while now.

Anyway...

A reliable source wispered to me that this problem may have been caused by a debug ECO bringing in a bad TRACE.EXE.

So you may want to recover from that ECO and/or contact support.

Good luck!
Hein.

[John Gillings]

Kjell,

DEBUGBOOT errors usually mean something is preventing the last chance exception handlers from working properly - usually catastrophic like a quota wall or misdirected image name. One possibility is a logical name "TRACE" (or in some cases "DEBUG") visible to the process.

For example:

$ DEFINE TRACE TRUE
$ RUN DIVZ
%DEBUGBOOT-W-FNF, file not found
%SYSTEM-F-INTDIV, arithmetic trap, integer divide by zero at PC=FFFFFFFF80D10E48, PS=0000001B

The exact conditon depends on the translation of TRACE. I haven't been able to work out a definition to generate PROTINSTALL, but I'm sure it's possible.

This is somewhat of a design flaw from the beginning of OpenVMS. By OpenVMS naming rules, the images should have contained a "$" in the name, maybe SYS$TRACE and SYS$DEBUG instead of the naked words.

It's highly likely that a programmer will choose to use obvious logical names DEBUG and TRACE for their own purposes, not realising that it will break the OpenVMS uses for the names. (but in my experience, it's something you only do once! ;-)

[John Gillings]

Found a way ;-)

This is a bit contrived, but it's feasible that a random file might look enough like a privileged image to get the same result:

$ copy sys$share:secureshrp.exe sys$login:junk.dat
$ define trace sys$login:junk.dat
$ run divz
%DEBUGBOOT-W-PROTINSTALL, protected images must be installed
%SYSTEM-F-INTDIV, arithmetic trap, integer divide by zero at PC=FFFFFFFF80D10E48, PS=0000001B

[John Gillings]

Kjell,

Another possibility, maybe TRACE is broken? Check to see if you have any earlier versions:

$ DIR SYS$SHARE:TRACE

Any earlier versions or .EXE_OLD? If so, repeat your experiment with TRACE defined to older images:

$ DEFINE TRACE SYS$SHARE:TRACE.EXE_OLD

If that helps, maybe back out the DEBUG patch or look for a newer one.

[DECxchange]

Could this be a data alignment issue? Check how you are compiling with Fortran and what qualifiers are being used. Maybe see if you are compiling with the alignment qualifier:
$ fortran
/align=(records=natural,commons=natural)

Check out $ help fortran/align as it gives other options as well. It kind of sounds like an array or record access violation. Are you using shared commons or global shared regions that need to be installed but aren't?

[John Gillings]

re: DECxchange

>Could this be a data alignment issue?

Simple answer - definitely not!

INTDIV and PROTINSTALL have nothing to do with array bounds or writable sections.

Alignment issues affect performance, not correctness. At worst unaligned data will make your program run slower than it could if the data were aligned correctly. You won't see unexpected fatal error conditions.

Incorrect attributes on shared commons will manifest at image activation as:

%SYS-F-NOTINSTALL, writable shareable images must be installed

[Kjell Carlsson]

I found that the files SYS$SSISHR.EXE and even SYS$SSISHRP.EXE are missing. I can't figure out why. Anyway I will upgrade to version 8.3.

Thanks for all the replies.

//kjell

[Kjell Carlsson]

Reinstall and update OpenVMS.