Operating System - OpenVMS
1748106 Members
4892 Online
108758 Solutions
New Discussion юеВ

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

 
SOLVED
Go to solution
Stephane Boneff
Advisor

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

Sorry but it's the 1st time that i use $Analyze /proc and I don't know language machine (only Z80 when I was young ;-) )

data in .TXT file

Stephane Boneff
Advisor

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

DBG> EXA/INS @PC-20:@PC+10

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)

DBG> EXA @FP+44
7EE5F904: 00000005 000105D8
Volker Halle
Honored Contributor

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

Stephane,

you code is trapping here:

CAL_BIL_COW\%LINE 7501: LDA R16,#XFFED(R31)
CAL_BIL_COW\%LINE 7501+4: GENTRAP <<<<

The updated PC after the trap is 0005A564, which points to these next instructions:

CAL_BIL_COW\%LINE 7700: LDA R16,#XFFF0(R31)
CAL_BIL_COW\%LINE 7700+4: GENTRAP
0005A56C: HALT

This is consistent with the value in R16

R16 = FFFFFFFFFFFFFFED

which is being loaded into R16 by the instruction: LDA R16,#XFFED(R31)

So your code is actually branching to L$5: (in the machine code listing) !

Unfortunatley there are a couple of branches to L$5: in the machine code listing.

So you code may not be executing where you think it is...

Volker.
Stephane Boneff
Advisor

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

Thank you for the time spent to help me !

"So you code may not be executing where you think it is..."

what dou you mean, Volker ?

I'm not sure to understand.

7501 : is it the Fortan line ? It's strange because 7501 is execute at the init of the process.




Volker Halle
Honored Contributor

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

Stephane,

your failing code is executing the GENTRAP instruction after label L$5: - this is for sure. This is declaring a SUBRNG1 error !

Try to NOT believe the line number reported (i.e. line 7700), but believe the PC value PC=0005A564 !

The SUBRNG1 error is taken, if a subscript of an array is out of range, i.e. out of the declared bounds, so look for array, not for strings.

There are lots of branches to L$5 in the machine code listing, you need to find 'THE ONE', which took you there !

Volker.
Volker Halle
Honored Contributor

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

Stephane,

most of the tests, which cause a branch to L$5 are for ranges of 1 to 9, but some are for 1 to 3. In many of the tests, R1 is being tested and in your dump, R1 IS 0 !

Look at the register values in the dump, e.g. R25 =1, so find out where R25 will be set to 1 in the machine code listing. If you find a branch to L$5 shortly after this, before the value of R25 is being changed again, look closer. R25 is typically the no. of argument to a subroutine call.

Volker.
Phil.Howell
Honored Contributor

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

Try compiling with /NODEBUG /CHECK=NONE
Jon Pinkley
Honored Contributor

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

I am trying to understand your advice "Try compiling with /NODEBUG /CHECK=NONE".

This may prevent him from seeing the error, but isn't that a bit like turning off memory parity checking to prevent getting memory parity errors?

Perhaps you have a good reason for the advice. If you have one, please let us know how this will help in determining the cause of the problem; it is not obvious to me, and I may be missing a useful technique.
it depends
Jon Pinkley
Honored Contributor

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

Stephane,

One thing I noticed from the listing file is

/OPTIMIZE=(INLINE=SPEED,LEVEL=4,SPECULATE=NONE,TUNE=GENERIC,UNROLL=0)

Most likely, this is the default for the FORTRAN compiler. However, for Debugging, it is normally recommended to use /NOOPTIMIZE on your compiles.

Optimization is one reason that the line numbers being reported by the debugger can be misleading, and why Volker said to trust the machine code, instead of a Fortran source code number. Even with /nooptimize, the debugger may report a different line than is really executing, but in general, there will be a closer correlation to machine code and FORTRAN code.

If turning optimization off results in an acceptably performing .EXE, I would recommend turning it off until you find the problem. Unfortunately, this can cause the problem to move, since you are no longer running the same program.

You said this has been working for years, then it started failing around the end of August. Can you think of anything that changed at that time? When was the last time the program was compiled/linked prior to the first occurrence of the %SYSTEM-F-SUBRNG1 error? Were any changes made to the system around that time. Any new sources of data? New users?

Something has changed, if it isn't the code, then it is due to differences in the data. Is the problem reproducible given the same input data? Is it possible to make copies of the date before the runs, so you can capture a case that causes the problem? (my guess is that this probably won't be an option, but intermittent problems are much harder to debug than reproducible ones). Is anything known about what was being processed when the failures occur?

Good luck,

Jon
it depends
Jon Pinkley
Honored Contributor

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

Stephane,

Another possible difference is timing and a latent synchronization issue. In the source and I see a reference to ASTs and COMMON variables.

EXTERNAL COWP_AST_FIN_POSTE ! relance AST fin poste


INCLUDE 'HPAPP_PAR:CAL_BIL_COW.CMN' ! D├Г┬йfinition des donn├Г┬йes communes aux modules

So it is at least possible that the data in the common area is being updated in an unsynchronized fashion, and therefore being corrupted.

Jon
it depends