Access Violation Error (runtime error #157) for allocated array?

[Nan_Deng]

I have a strange bug and I need some help.

I am modifying an old code to add new functionalities of an existing subroutine. There are six validation problems for this routine. Five of the six run smoothly for both the old and new (modified) versions and the results are identical. However, on the sixth problem I run into the "access violation" runtime error message for the new version. Funny thing is: the first time the program gives the error, it gives a long list of "unknown" list of the routines with no trace back information (I turned the /traceback on). But from the second time, it gives traceback line numberat the statement of "If (allocated (ss)) deallocate (ss)" (ss is the array name). If I comment this statement out, then traceback gives the line number at the end of the subroutine.

I would like to hear experts' opinion on what would cause this problem, and how can I fix it?
(I use visual fortran only, mixed with f77 and f90 statements, no other language involved).

[Nan_Deng]

Is there any limits on how many levels of allocated array one can specify? The program may have upto 10 levels of subroutine calls with around 200 allocatable arrays. Would that be the problem that the compiler get confused? (I use 11.1.054)

[anishtain4]

I'm just having the same problem, when the size of the allocatables increase (not a big number!! I have one 547, one 480 and another 13*61 arrays) the program crashes, in Debug it says: "triggered a break point" but I don't have any, after that when I want to proceed it says no source code available.
When I run it in release the error is same as Nan Deng gets.

[jimdempseyatthecove]

Is ss a dummy arg? A pointer to an array? A local array without SAVE? A local array with SAVE?
The return of a function? Is the subroutine/function recursively called? Is the referenced used within an OpenMP parallel region? Is ss allocated within this routine?

Is your program calling C/C++ or other language routines (excluding the runtime libraries)?

If your routine performs the allocation, does the allocation statement have the allocation status arg and which the code ignores the return status?

Jim Dempsey

[jimdempseyatthecove]

I forgot to mention:

IVF uses the C Runtime Library heap. Memory allocations from the C heap contain links and size information preceding the returned address. If this information gets corrupted then the deallocation will (may) report an error (or you may unexpectedly crash some time later than the corruption). Check your code to see if you have index out of bounds problems, or buffer overrun (e.g. allocate a buffer, pass buffer address/reference to external I/O routine, I/O reads past end of buffer). This means either you are indexing ss prior to its first index .OR. indexing past a different array that precedes ss in memory.

Try running your code with the array subscripting checks (it is not unusual for the error not to be detected and forthe problem symptom to dissappear). Also enable gen-interfaces/warn-interfaces.

If nothing obvious shows up then in your code insert immediately after your allocation of ss:

if(allocated(ss)) deallocate(ss)
allocate(ss(sizeOfss))

Then run the program. It should succeed. If it succeeds, move the two statements further down in your code. (ignore the fact that you will be destroying your results data). What you are looking for is the point in the code where your memory corruption occurs. You could also modify the above two statements to copy ss to a scratch array, deallocate, reallocate, copy back from scratch array.

Hopefully the bug persists enough for you to catch it. Sometimes inserting diagnostic code makes the symptoms go away or go elsewhere.

Jim Dempsey