topic Without seeing the program, in Intel® Fortran Compiler

what is the meaning of this error message

Brian_Murphy — Tue, 16 Jul 2013 14:37:30 GMT

I am running a numerical analysis code in a console window and get the following error message. What does it mean, and why is there no routine and line number for the offending line in my code??? forrtl: severe (153): allocatable array or pointer is not allocated Image PC Routine Line Source libifcoremdd.dll 001CFA8A Unknown Unknown Unknown Stack trace terminated abnormally.

The error message means that

Steven_L_Intel1 — Tue, 16 Jul 2013 14:43:37 GMT

The error message means that you tried to deallocate an allocatable variable that was not allocated. But the other lines indicate that the stack has been corrupted by your program and it can't find the proper traceback data. Possibly you wrote outside the bounds of an array. You could run the program under the memory analysis feature of Intel Inspector XE and it might show you the problem. You can get a free 30-day trial of Inspector XE if you don't already have it.

Steve,

Brian_Murphy — Wed, 17 Jul 2013 18:31:58 GMT

Steve, I have installed the Inspector XE Trial and have tried to run one of the tutorial samples that came with it, but I got an error about not having the right license

If you're trying the Static

Steven_L_Intel1 — Wed, 17 Jul 2013 19:04:23 GMT

If you're trying the Static Analysis tutorial, that requires a Parallel Studio XE or Fortran Studio XE license. The Memory Checker should work.

Forgive my ignorance, but I

Brian_Murphy — Wed, 17 Jul 2013 22:12:03 GMT

Forgive my ignorance, but I don't know what a static analysis is. What tutorial should I run to learn how to use the Inspector. As it is now I've got the code running in the debugger, but weird things happen when stepping one line at a time using F10. At statements that do something like A = 0.D0 where A is a 40 by 40 matrix, the debugger goes into limbo for about 30 seconds before I can step another line. But using F5 it would fly right through it. Is this normal? Thanks, Brian

In VS2012 I did Tools/Intel

Brian_Murphy — Wed, 17 Jul 2013 22:34:32 GMT

In VS2012 I did Tools/Intel Inspector/Locate Memory Problems and after about a minute of running through the program, it seems to have found a bunch things, but a lot of them make I don't know what to make of. Here's an example. Why would this statement generate an Invalid Memory Access error? OPEN(UNIT=IOUT, FILE="DefFLBear.inp") IOUT has been assigned a value of 21 a few lines earlier

>> A = 0.D0 where A is a 40

jimdempseyatthecove — Wed, 17 Jul 2013 23:12:44 GMT

>> A = 0.D0 where A is a 40 by 40 matrix, the debugger goes into limbo for about 30 seconds

When check for array index out of bounds, unfortunately this is the case. It check 1600 times. With a little extra work, the compiler writers could fix this. When I come up to this when debugging with array bounds checking enabled, I place the mouse on the next line, Right-click and select Run to Cursor.

>>Why would this statement generate an Invalid Memory Access error? OPEN(UNIT=IOUT, FILE="DefFLBear.inp") IOUT has been assigned a value of 21 a few lines earlier

Can you fix the other "bunch of things". The message you receive on the OPEN may be a side effect of the other errors.

What is the file extension of the source code files you are compiling? If yourName.F (*.F) these are fixed format files (F77 and earlier). This file format has explicit requirements as to which columns the statements are to be positioned....
The TAB character is one position regardless of how your editor (VS) displays the code. I suggest, if possible, to change the file type to .F90. This is free form.

Jim Dempsey

Without seeing the program,

Steven_L_Intel1 — Wed, 17 Jul 2013 23:13:48 GMT

Without seeing the program, it's hard to say what this means. But I'd expect that something is corrupting memory - your symptoms hint at that and the odd Inspector results do also.

The F10 issue is that the debugger has to single-step instructions until it reaches the next statement. Your array assignment is a lot of instructions, so it takes a while (single stepping is slow).

>>The F10 issue is that the

jimdempseyatthecove — Wed, 17 Jul 2013 23:29:36 GMT

>>The F10 issue is that the debugger has to single-step instructions until it reaches the next statement. Your array assignment is a lot of instructions, so it takes a while (single stepping is slow).

Correct, but in the case of A=0.0 or A=B, the compiler generates the index range and should know that it is impossible to index out of range. Knowing this, it should then generate the code sequence without subscript testing. The subscript testing is the major cause of the slow down.

Jim Dempsey

Quote:jimdempseyatthecove

IanH — Thu, 18 Jul 2013 01:18:57 GMT

jimdempseyatthecove wrote:

>>The F10 issue is that the debugger has to single-step instructions until it reaches the next statement. Your array assignment is a lot of instructions, so it takes a while (single stepping is slow).

Correct, but in the case of A=0.0 or A=B, the compiler generates the index range and should know that it is impossible to index out of range. Knowing this, it should then generate the code sequence without subscript testing. The subscript testing is the major cause of the slow down.

Jim Dempsey

I'm not so sure about the last bit. The debug subsystem and debugger have a good old yarn for each instruction executed by the debugee that is associated with the statement being stepped over - I think because the debugger wants to know if execution has moved off that statement (execution doesn't necessarily progress to the next statement in the general case) as part of the definition of what a "step" in source code is. Array subscript tests increase the number of instructions, but the basic problem is that a lot of instructions are executed for that one statement - it's still slow if array subscript tests are off.

When you run to the run line (rather than stepping) the debugger can just do the int 3 trick that you are familiar with (or something equivalent), then sit back and wait for the fireworks.

The array in A = 0.D0 is only

Brian_Murphy — Thu, 18 Jul 2013 13:44:50 GMT

The array in A = 0.D0 is only 40x40 (1600 values), but could just as easily have been 400x400 or 4000x4000. If it takes 30 seconds for 40x40, will it take 30 times 100**2 (300,000) seconds for 4000x4000? I don't think I want to find out. I understand that using F10 to step through code slows things down immensely. Steve's remarks make it sound like pressing F10 on A = 0.D0 is akin to pressing F10 1600 times. If that's right, it could explain the 30 seconds of limbo. But you sure wouldn't want to do this on a really big array. Here's a related question. If an array assignment statement like A = B(N1:N2) is overstepping array bounds, does it matter whether this statement is executed via F10 or F5?

>>...forrtl: severe ( 153 ):

SergeyKostrov — Thu, 18 Jul 2013 14:16:00 GMT

>>...forrtl: severe ( 153 ): allocatable array or pointer is not allocated If the error 153 was returned by GetLastError Win32 API function than it means: 153 - The DosMuxSemWait list is not correct ( ERROR_INVALID_LIST_FORMAT ) Unfortunately, it doesn't explain what happened during processing.

This is a Fortran error 153,

Steven_L_Intel1 — Thu, 18 Jul 2013 14:20:51 GMT

This is a Fortran error 153, nothing to do with Win32 API errors.

Jim, I did a test and did not

Steven_L_Intel1 — Thu, 18 Jul 2013 14:25:38 GMT

Jim, I did a test and did not see any bounds checking code for a whole array assignment.

I forget to say that I am

Brian_Murphy — Thu, 18 Jul 2013 14:38:29 GMT

I forget to say that I am using .f90 for all file extensions. Brian

One other thing to look at,

jimdempseyatthecove — Thu, 18 Jul 2013 14:57:25 GMT

One other thing to look at, which should be caught by uninitialized (undefined) variable runtime test, is if your code has a branch around initialialization (do once) code:

IF(DidThisIndicator) GOTO 100
DidThisIndicator = .true.
... ! do once code
100 continue

The problem being the older F70 code may have worked more by accident than by design. Some of the older compilers, including CVF would default to making scalars to SAVE when the procedure was not recursive. The newer versions (e.g. IVF), these are automatic (stack). Thus if the do once code contains pointer initialization (of local variables), the(se) pointer(s) would be valid for the first call, and depending on circumstances:

a) may accidentaly be correct
b) may be incorrect and point to valid virtual machine address (corrupting code/data or using junk/or invalid/unallocated pointer)
c) may be incorrect and point to invalid virtual machine address (Seg Fault)

The correction will require for variables (pointers, array descriptors, data) that are requred to be SAVE, for you to explicitly add SAVE to the attribute. And conversely not add SAVE to those variables not required to be SAVE, as this may mess you up later should you want to code multi-threaded (e.g. OpenMP).

Jim Dempsey

Brian, you earlier asked

Steven_L_Intel1 — Fri, 19 Jul 2013 18:47:35 GMT

Brian, you earlier asked about tutorials. Inspector XE provides several of these with the product - you should go through them. You can open the Inspector XE GUI separately (from the Start menu) and click Getting Started, or just open file:///C:/Program%20Files%20%28x86%29/Intel/Inspector%20XE%202013/documentation/en/tutorials/index.htm in a web browser.