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

[Volker Halle]

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]

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]

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]

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]

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.

[Stephane Boneff]

Voker,

I have 3 dumps.
I can't copy them from the alpha (FTP gives an error "550 illegal record encountered; VBN or record number = !UL"
(FTP, in bin format)

In the dump :
"Link Date 21-SEP-2009 15:17:49.16"

For the registers, see in .TXT, there are the values extract with $analaze /proc/full.

In the 3 dumps, the PC is the same.

But the variable as COWP is different.

[Volker Halle]

Stephane,

interesting ;-)

Nearly ALL of the registers in the 3 dumps are the SAME, except:

R0 and R26 ! But R0 + 10. always is R26 !

Try to work out the context from the register values, especially R2, R13, R17, R28

DBG> SET LAN MAC
DBG> EXA @Rx

Also some registers seem to point to the stack (adresses 7xxxxxxx) or at least into P1 space. Examine the data at those addresses:

DBG> EXA @R12

As far as analyzing process dumps: in the old versions of OpenVMS Alpha (before V7.3-2), process dumps nearly always could only be analyzed on the system, where they have been written. Take this into account, if you consider to call in help.

Volker.

[Volker Halle]

Stephane,

what are the values of COWP in each of the 3 dumps ?

Volker.

[Stephane Boneff]

Volker,

R26 is the value of variable "COWP".


(for the Dump, I understood that I have to use the same machine to do the Analyze, I tried on the DEV machine but it don't work)

I have an idea : I can add a variable as "line" in the .FOR

Every paragraph, i put a value in it.

with the dump, i will be able to read the last value of "line".

What do you think of that ?
Can it be usefull ?

(again, thanks for the time spent helping me , I really appreciate it)

[Volker Halle]

Stephane,

please examine the register values as asked for in my previous reply.

Also provide the value of 48(R2) - ideally from all of the dumps:

DBG> SET LAN MAC
DBG> EXA @R2+30

I have at least located an instruction, which might explain the value in R0:

997C: SUBL/V R26, R4, R0

Still a puzzle...

Volker.

[Volker Halle]

Stephane,

is your application using RMS journaling ?

Volker.

[Stephane Boneff]

Volker :

I don't know what is RMS journaling but I suppose that the application don't use it.

the process is run by :

$ RUN /NODEB -
/DETACH -
/DUMP -
/UIC = U_PROC_HFX -
/OUTPUT = HPMAI_DAt:cal_bil_cow.out -
/INPUT = HPAPP_COM:CAL_BIL_COW.COM -
/ERR = HPMAI_DAT:CAL_BIL_COW.ERR -
/PRIV = (NOALL,TMPMBX,GRPNAM,NETMBX,PRMMBX,SYSNAM) -
/PROC = HP_CAL_BIL_COW -
SYS$SYSTEM:LOGINOUT

For the registers, you want the value @R2 ?
ex :
DBG> exa @R2
CAL_BIL_COW: 011030D9
DBG> exa /inst @R2
CAL_BIL_COW: LDA SP,#XFEC0(SP)

or
DBG> exa %R2
CAL_BIL_COW\%R2: 00000000 00010568

[Volker Halle]

Stephane,

please exactly use the commands I've given you:

DBG> SET LAN MAC
DBG> EXA @R2
DBG> EXA @R2+30
DBG> EXA @R13
DBG> EXA @R17
DBG> EXA @R28
DBG> EXA @R12
DBG> EXA @R15

Do you see a license, if you issue the command $ SHOW LIC RMSJNL ?

Volker.

[Stephane Boneff]

Volker,

No license for RMSJNL.

see values in .TXT
for the 3 dumps, the values are the same.

[Volker Halle]

Stephane,

@R2+30. points to address 10002C, which is the address of the STATUS variable in .PSECT $BSS$ (at offset 2C in this PSECT). This data PSECT starts at 0x10000 in virtual memory.

In the machine code listing, you'll often see constructs like:

LDQ R16, 48(R2)
LDL R16, 44(R16)

This is moving the value of COWP into R16.

LDQ R25, 48(R2)
LDL R25, 8(R25)

This is moving the value of I into R25.

NOTE: the offsets in the machine code listings are in DECIMAL, whereas DBG (after SET LAN MAC) wants them in HEXADECIMAL.

DBG> SET LAN MAC
DBG> EXA 10002C+2C ! should show COWP
DBG> EXA 10002C+8 ! should show I

Volker.

[Stephane Boneff]

Volker,

It's exact :
DBG> EXA 10002C+8
CAL_BIL_COW\I: 0000000A

and
DBG> EXA 10002C+2C
CAL_BIL_COW\COWP: 00000004

[Volker Halle]

Stephane,

how about

DBG> EXA 10002C+30 ! should be AUTRE_COWP

In general one needs to either check the source code, if any subscript of any array could have exceeded the allocation size of the array. Or one needs to analyze the machine code (ideally the complete instruction stream from the .DMP file itself !) to find out, if there are any execution passes leading to L$5 with the correct values of the registers as seen in the dump. Until now, I have not found such a code path, but I'm checking against the machine code listing and not against the actual machine code inside the .DMP file !

Volker.

[Dennis Handly]

>Volker: Or one needs to analyze the machine code

If range checking was implemented without much concern for performance, you wouldn't need to look at the machine code. The error message should tell you the name of the variable, index, bounds, file and line number.
I believe the +check= option on HP-UX does this.