CVF6.6 Error - Severe (22): Input record too long

[mohanmuthu]

Hi,

I use CVF compiler 6.6 to compile my code, wherefew subroutines are called over loop'n' times. At certain 'n', I get the error message 22# Input record too long. I wonder, it read same input file for all the execution performed till that loop, and why this error now.

When I looked at the PF usage in task manager, I see PF usage is increasing slowly and when error occurs, it fall backs to a lower number. Interesting point is, PF usage when the program crashes is much less that what my computer is capable of. Some other application like ANSYS runs with much higher PF usage.

I suspect, program compiled with CVF6.6 is accumulating memory even after coming out of subroutine. Because, during (DO) loops, no additional variables are initiated.

Is there any command, that would help me clearing the memory or is there any tool I can use to see which area is causing this trouble?

Thanks,
Mohan

[Les_Neilson]

It would be nice to see some actual code but, from your description of the error message, it seems likely that you have
(a) OPENed a file with a RECL=value
and
(b) in your filethe record at position "certain 'n'" is longer than .

Can you show us the code where you OPEN the file and the DO loop where youREAD the file including anyFORMAT statement?
It might also help if you show us the declarations of the variable(s) that are being read.
A real bonus would be the contents of the file at the point where the program fails.


How was your input file created?
Are you able to edit it and examinerecordnumber 'n'?

The memory usage probably has nothing to do with the error message. If it is a real separate problem though then you would need to give us more information about your program including showing us some code. It has been many, many years since I used CVF

Les

[mohanmuthu]

Attached the code below, which is iterated. Since the same input data is accessed for several times, tmp.bin isthe binary file created before starting the loop. It hasseveral records of variable length, whose length is defined by n3(x).

Approx,after 17000 loops, I get the error while opening the same binary file. I assume, because of some memory accumulation onlyprogram crashes.

Thanks very much

~~~~~~~~~~~~

!! find the linear vec mult
SUBROUTINE sub1(r1,r2)
USE globalvariables !! where other constants are defined
IMPLICIT NONE
REAL*4, INTENT(IN) :: r1(n1)
REAL*4, INTENT(OUT) :: r2(n2)
REAL*4, ALLOCATABLE :: r3(:,:)
INTEGER :: i1
OPEN(99,FILE='tmp.bin',FORM='UNFORMATTED')
DO i1=1,n2
ALLOCATE(r3(n3(i1)))
READ(99)r3
r2(n4(i1):n5(i1))=MATMUL(r3,r1)
DEALLOCATE(r3)
END DO
CLOSE(99)
RETURN
END SUBROUTINE sub1

[Les_Neilson · Accepted solution]

OK The allocate of r3 is dependent on the value of n3(i1) Is there a possibility that the contents of n3 are being modified somewhere so thatthe value of n3(i1) no longer represents the length of the record? That seems to be the most logical conclusion.
Or
It might also be a good idea to add a STAT= to the allocate statementso that you can see if the allocate fails - perhaps if there are other allocations happening in the code which don't get deallocated until later and memory fragmentation is preventing a successfulallocation.
Note: if you use Fortran POINTERs these are prone to memory leaks.
I know nothing of how good CVF's memory management is in comparison to todays compilers but there must have been some improvement there over the years.

Les

[mohanmuthu]

Thanks a lotLes!!

I use one pointer where this routine is called. Let me try changing to a allocatable array with global definition. I hope, that should solve the problem :-).

[mohanmuthu]

Les, you got it right. It was the pointer causing problem. After I changed to allocatable array, it works great.

Many thanks to you.

[Les_Neilson]

You are welcome. I'm glad it is now working for you
Les

[mecej4]

It was probably not reasonable for you to ask for help with a malfunctioning code without showing array declarations, particularly since the fix that you found involved code that you did not even describe, let alone show.

In such circumstances, the possibility exists that the fix that you made may have masked or moved the problem instead of actually rectifying the defect.