Operating System - OpenVMS
1747980 Members
4739 Online
108756 Solutions
New Discussion юеВ

Re: Error Subscript 1 range error impossible to solve (Alpha VMS 6.2)

 
SOLVED
Go to solution
Phil.Howell
Honored Contributor

Re: Error Subscript 1 range error impossible to solve (Alpha VMS 6.2)

Jon - The original poster said "it has been running fine for years", but there was no indication of how this "good" version was compiled.

The listing supplied also differed from the original post as regards /DEBUG and /OPT
(not to mention /ALIGNMENT)

Maybe after the first crash it was compiled with /CHECK for the first time and all we are seeing now is the result of that runtime check.

I have also learned over the years that there are some bugs that refuse to show themselves in a executable with debug.

I should also have included the suggestion to put
$ set process /dump
before running this program, then we would have real evidence.

Also my French is as rusty as my Fortran so I wasn't going to spend any time looking at the code.

Phil
Stephane Boneff
Advisor

Re: Error Subscript 1 range error impossible to solve (Alpha VMS 6.2)

(I'm back at work)

for Phil and Jon :

my answers :
-------------

The last build before the crash : 2007/07.
Fist crash : 2009/08/26


For the .EXE, the flags are :
/DEBUG/NOOPT/EXTEND/CHECK=ALL/CONT=60/NOALI/NOWAR

/DEBUG/TRACE/MAP:HPAPP_OBJ:

For generate the .LIS, i made the mistake to do "FT /NOOBJ/LIS" (sorry ...)

here is a .LIS with the real options (in .TXT) that are used for the crashing .EXE module.

Do with :
"FORTRAN /OBJECT=HPAPP_OBJ:CAL_BIL_COW /DEBUG/NOOPT/EXTEND/CHECK=ALL/CONT=60/NOALI/NOWAR/LIS /MAC"


The AST "COWP_AST_FIN_POSTE"
don't modify any data of the common.

For the /CHECK : the module has been always built with /CHECK=ALL

(And /NOALI)

(With a .MMS file )
Phil.Howell
Honored Contributor

Re: Error Subscript 1 range error impossible to solve (Alpha VMS 6.2)

does this run as a batch job? detached process?
if so, insert this line before the run command
$ set process /dump
then when it crashes, it will write a dump file.
If you can run it from an interactive session, then run /debug and at the debug prompt
DBG> set break /exception
DBG> go
then when it crashes you can examine away

comp.lang.fortran always welcome a puzzle too

Phil
Stephane Boneff
Advisor

Re: Error Subscript 1 range error impossible to solve (Alpha VMS 6.2)

yes, I have a .DMP to analyze (thanks to Volker).

I trying to understand it (the 1st time for me).

in debug of .DMP, with
EXA/INS @PC-200:@PC+10

If I read it correctly, the program reach to is end (line 8556) and then
a exit handler is called :

CAL_BIL_COW\%LINE 8553+0E8: BIS R31,#X05,R25
CAL_BIL_COW\%LINE 8553+0EC: BIS R31,R31,R31
CAL_BIL_COW\%LINE 8553+0F0: LDA R27,#X06F8(R2)
CAL_BIL_COW\%LINE 8553+0F4: BSR R26,#X000010
CAL_BIL_COW\%LINE 8556: BIS R31,#X01,R0
CAL_BIL_COW\%LINE 8556+4: TRAPB
CAL_BIL_COW\%LINE 8556+8: BIS R31,FP,SP
CAL_BIL_COW\%LINE 8556+0C: LDQ R26,#X0110(FP)
CAL_BIL_COW\%LINE 8556+10: LDQ R2,#X0118(FP)
CAL_BIL_COW\%LINE 8556+14: LDQ R3,#X0120(FP)
CAL_BIL_COW\%LINE 8556+18: LDQ R4,#X0128(FP)
CAL_BIL_COW\%LINE 8556+1C: LDT F2,#X0138(FP)
CAL_BIL_COW\%LINE 8556+20: LDQ FP,#X0130(FP)
CAL_BIL_COW\%LINE 8556+24: LDA SP,#X0140(SP)
CAL_BIL_COW\%LINE 8556+28: RET R31,(R26)
CAL_BIL_COW\%LINE 7501: LDA R16,#XFFED(R31)
CAL_BIL_COW\%LINE 7501+4: GENTRAP
CAL_BIL_COW\%LINE 7700: LDA R16,#XFFF0(R31)
CAL_BIL_COW\%LINE 7700+4: GENTRAP
0005A56C: HALT
AFFICHE_LOG_ERREUR: LDA SP,#XFDF0(SP)
AFFICHE_LOG_ERREUR+4: STQ R31,#X0020(SP)
Jon Pinkley
Honored Contributor

Re: Error Subscript 1 range error impossible to solve (Alpha VMS 6.2)

Stephane,

What is in the common? Is it writable by more than one process/thread? If so, how is access controlled?

If the days where the application crashed 3 times just happened to be "busy" days, that could explain the behavior, especially if array subscripts are being passed back and forth in the common.

In other words, if there were never many concurrent writers, you may have been lucky for a long time.

If there are not multiple writers to the common memory, then that probably isn't related to your problem.

Jon
it depends
Volker Halle
Honored Contributor

Re: Error Subscript 1 range error impossible to solve (Alpha VMS 6.2)

Stephane,

it is absolutely crucial to have the IDENTICAL machine code listing with the SAME qualifiers etc. available, with which the image, which created the .DMP file, has been built. Otherwise you really have to look at the instructions in the dump itself !

The dump analysis is hard work. You need to answer the following question:

- the code is reaching the first GENTRAP instruction labeled L$5 in the machine code listing, where it loads -19 into R16 and takes the trap. This can be confirmed by the contents of R16 in the dump ! The updated PC points to L$102, which may be the reason, why line 7700 is reported as 'the failing source code line'.

- you need to examine, HOW the code could have reached label L$5. There are lots of branches to this label, so you also need to examine the current register values to back-track, where the branch has been taken from.

For this to be succesful, you MUST HAVE the correct machine code listing, otherwise you need to really decode all the instrcution in the dump.

Volker.
Volker Halle
Honored Contributor

Re: Error Subscript 1 range error impossible to solve (Alpha VMS 6.2)

Stephane,

without any knowledge about Alpha machine code instructions and no experience with dump analysis, you will very soon get completely lost...

If this is an important problem for you to solve, try to collect a couple (2-3) of .DMP files and contact me offline via e-mail (click on my forum username).

Volker.
Stephane Boneff
Advisor

Re: Error Subscript 1 range error impossible to solve (Alpha VMS 6.2)

Volker,

The .EXE :
CAL_BIL_COW.EXE;9 21-SEP-2009 15:17:52.00

The .FOR :
CAL_BIL_COW.FOR;35 21-SEP-2009 15:15:44.04

The .LIS (is it used by analyze /proc) was produced from the .FOR, today.

Is it correct ?
Hoff
Honored Contributor

Re: Error Subscript 1 range error impossible to solve (Alpha VMS 6.2)

Presuming no code changes in the Fortran stuff.

It is quite possible this is a latent code bug; code that runs is not code that is free of defects. There are fully documented cases of nasty bugs that have been latent in code that's been very actively used for thirty years.

While I would certainly not rule out the latent bug(s) that the others are discussing here, I would broaden the search somewhat.

See what software and what patches been installed for the last year or so; since (well) before the crashes. Look in the PCSI history and in the VMSINSTAL history, and in the histories of any constituent products.

If you're "cornered enough", I'd also look for and install Fortran updates and OpenVMS Alpha V6.2 ECO kits.

Also check for hardware errors.

And confirm you're not blowing out a system resource; the size of that dump implies this application is large and complex, that the process requires substantial quotas, and it implies you could (depending on what that code is doing) blow out the 30-bit address space that was available prior to OpenVMS Alpha V7.0. You're basically running on a VAX here, in terms of the addressing that's available. It's been my experience that old applications tend to have gaps in the error handling for these cases, and that the errors that can be manifested aren't always clear-cut VM-related errors.

And yes, look to call in help.
Volker Halle
Honored Contributor

Re: Error Subscript 1 range error impossible to solve (Alpha VMS 6.2)

Stephane,

and the .DMP is dated from ? Produced by the .EXE linked 21-SEP-2009 15:17:52:00, right ?

ANAL/PROC is using the .FOR file, not the .LIS file.

If you have created the latest .LIS file from the same .FOR file using the SAME qualifiers and FORTRAN version, it should contain the same machine code as is present in the image and therefore also in the process dump file.

If you can, collect a couple of .DMP files and compare them, especially all the register values - assuming that the error and the reported line number are always the same.

Volker.