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

[Stephane Boneff]

Hello,

i have a dark problem with a Fortran process.
I have been running fine for years.
Since end of august, it is crashing randomly with error "Subscript 1 range error".

The line :
IF ((val_c(Cowp:Cowp) .NE. ' ') .OR. (Memo(cowp).date_fin_poste .NE. ' ')) THEN

With a .DMP, i verified that every variable is ok (cowp = 6, val_c is a string of 132 long, Memo is a array of 9).
(with Analyze /dump /ima xxxxx)

compil option :
/DEBUG/NOOPT/EXTEND/CHECK=ALL/CONT=60/NOALI/NOWAR

link flag :
DEBUG/TRACE/MAP:HPAPP_OBJ


Since the fist crash, the .EXE has been remake manu time with no change.

It can crash 3 time a day and not crash for 4 days.

One expert of my compagny don't undertand this problem.

Do you have some idea ?

Thanks

[Volker Halle · Accepted solution]

Welcome to the OpenVMS ITRC forum.

Could you please show the real error message (with cut & paste) ?

And also provide a session log file of your analysis session (in an attached .TXT file) ?

'Dark problems' presented with insufficient information may remain a mystery...

Volker.

[labadie_1]

Can you post your version of Fortran ?

$ anal/ima/int sys$system:fortran.exe followed by 4 or 5 returns should show it.

[Steven Schweda]

> $ anal/ima/int sys$system:fortran.exe [...]

"FORTRAN /VERSION" might be easier, if it's
not too old.

[Stephane Boneff]

thanks for your help !

version of Fortran :
DEC Fortran for OpenVMS AXP Systems v6.3-711
(from a .LIS source)


full error message :
%SYSTEM-F-SUBRNG1, subscript 1 range error, PC=0005A564, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
Image Name Module Name Routine Name Line Number rel PC abs PC
CAL_BIL_COW CAL_BIL_COW CAL_BIL_COW 7700 0000A564 0005A564
CAL_BIL_COW 0 000CD5EC 000DD5EC
DEC$FORRTL 0 00072818 00898818
CAL_BIL_COW 0 000CD5EC 000DD5EC
0 85822170 85822170

With the source code, the crash is impossible :

- the index COWP is in a Do 1,MAXI loop (MAXI=9)
- for the array MEMO, the dim is MAXI
- val_c is a 132 long characters string.

what is "analysis session" ?

I only use Analyze /proc with a 51000 blocks dump file (which is impossible to provide here).

I put the .LIS of the source.
(tilt on line 7700)

[Volker Halle]

re: 'analysis session'

Just invoke ANAL/PROC on the dump and examine the current variables, Alpha instruction stream etc. and capture this in a .TXT file (with cut & paste).

Volker.

[Volker Halle]

I'm assuming, the SUBRNG1 error is being generated by the GENTRAP instruction at offset 66D4 (label L$102: in machine code listing).

There are a couple of branches to L$102 in the instruction stream for line 7700. You would have to try to re-do the Alpha instructions in your head and try to figure out, which branch took you to L$102:

In ANAL/PROC, issue the command:

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

to identify the instruction stream you're in. Then look at all the registers and the variables.

Volker.

[Stephane Boneff]

the asked data are in the file .TXT


thanks.

[Stephane Boneff]

VMS version : OpenVMS V6.2-1H2

Machine :AlphaStation 400 4/166

memory : 256 Mb


Tell me if you need other information.

[Volker Halle]

Please provide the output of:

DBG> SET LAN MAC
DBG> EXA/INS @PC-20:@PC+10
DBG> EXA @FP+44

Volker.

[Stephane Boneff]

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]

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]

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]

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]

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]

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]

Try compiling with /NODEBUG /CHECK=NONE

[Jon Pinkley]

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.

[Jon Pinkley]

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

[Jon Pinkley]

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

[Phil.Howell]

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]

(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]

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]

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]

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