Windows /heap-arrays compiler option

[mangipus]

Hi,

We are facing a problem with respect to /heap-arrays compiler option.

When we compile our application with /heap-arrays:1 (in kb) compiler option and runs our final executable, it crashes sometimes with "Program Access Violation" or some times with the error "Stack trace terminated abnormally". But, if we remove /heap-arrays compiler option then application runs fine. We added this compiler option, because our application uses intensive local arrays.

Later, I used Fortran debugger (idb) to debug the application. When I used debugger that time debugger is throwing following error while returning from one of our function

HEAP[bmin.exe]: Invalid Address specified to RtlFreeHeap( 0E760000, 0E05AB70 ).

I get this warning whenever I return from that particular function and after some time program is crashing with following error:

========

Heap corruption detected at 0EA2DBD8

HEAP[bmin.exe]: HEAP: Free Heap block ea2dbd0 modified at ea2dbe0 after it was freed

Thread generated exception: Access Violation

======

Any idea for such a problem? In addition to that I would like to know some more fact:

1. Does /heap-arrays compiler option adds only local array variable of function into the heap?

2. Does /heap-arrays compiler option puts formal parameter of function into the heap?

3. Does /heap-arrays:1 compiler option puts only those array variable which are greater > 1kb?

Becoz, when I print address for local variable , local arrays variable < 1kb, local arrays variable >1kb and heap variable (allocated on heap using allocate statement), then address range for local variable, arrays variable (irrespective of arrays size) and heap variable is entirely different. I understand range difference between local variable and heap variable, but still I do not understand why arrays variable are being put entirely at different address range. Becoz in C local array variables are close to local variable, which means those are being put on stack.

Surprisingly, I get same address with /heap-arrays or without /heap-arrays compiler option.

If someone can explain it, it will be greatly appreciated.

Thanks,

Vipin

[jimdempseyatthecove]

Vipin,

Perhaps it would helpif we saw the subroutine header and array declarations. As well as compiler, version, operating system.

Also, the omission of an option does not necessarily turn off an option (it reverts to the default setting, whatever that may be). When in doubt, use the debugger to examine the preamble code of the subroutine to see if it allocating the array from the heap.

Jim Dempsey

[mangipus]

I am using Intel Fortran comiler for object file creation, following is the version information of compiler:

Intel Fortran Compiler for 32-bit applications, Version 9.1 Build 20070109Z P
ackage ID: W_FC_C_9.1.034

Executable is created using Microsoft Visual Studio 2003 .NET linker.

Microsoft Incremental Linker Version 7.00.9955

=============================

I examined that preabmle code of subroutine in debuggerand found that there are couple of for_allocate function call just before entering into subroutine and couple of for_deallocate function call just before returning from subroutine when I compile program using /heap-array compiler option. Crash is happening in later part (just before returning from subroutine). If I do not use /heap-array compiler option, then there is no for_allocate and for_deallocate function call in preamble code of subroutine.

Program is very complex, so it is not possible for me to create a small testcase. It would be very helpful if you can confirm exactly in what scenario /heap-arrays compiler option is used and where exactly it allocates memory. Is it in same heap range where user allocate memory using ALLOCATE statment?

[jimdempseyatthecove]

One potential source of such problems is when linking with other object files compiled with a different calling convention and whereby the calling convention is not declared or not declared properly in the Fortran code. What this oftenproduces is upon return from call is that the argument list, which was pushed on the stack,is not cleaned off the stack (or cleaned twice).

A second source of the problem is where the array descriptor is being corrupted. Depending on compiler options, the array descriptor may be in static memory or it may be in the stack frame. Should you compile such that the array descriptor is in static memory then you must make certain that the subroutine/function is not called in a re-entrant (or recursive) manner.

A third source of the problem is when the array descriptor is on the stack as well as other items on the stack and the other items are written beyond the bounds of the item (thus corrupting the contents of the array descriptor).

A fourth source of the problem, is when the array descriptor has not been corrupted, but other errant code corrupts the heap.

A fifth source could be compiler error.

Not being from Intel Software Support I cannot advise you if there are known compiler errors. You should be able to diagnose the first four potential sources for such errors.

Jim Dempsey

[mangipus]

Hi,

I tried following compiler option in debug build (source compiled with /Zi option)-

/check:pointer -> program crashed with Floating point overflow exception and stack terminated abnormally. No traceback information even /traceback option used during compilation.

/check:bounds -> same error as mentioned above.
/check:output_conversion -> same error as mentioned above
/check:uninit -> same error as mentioned above.
/check:all -> same error as mentioned above.
/check:format -> This time program crashed with "Program access violation error". It showed traceback also, but traceback is pointing to a post preamble code of function (code which is added by compiler after RET statment for stack unwinding ).

Any guess, what could be a reason of giving different error in /check:format option??

/fpe:0 -> I used this compiler option, in this case program crashed with "floating point overflow error" and showed traceback.
Can you please tell me what is wrong in following code:
=============================
REAL xx,yy,zz,xi,yi,zi
REAL b1,b2,b3,c1,c2,c3,d1,d2,d3,e1,e2,e3
REAL t1,t2,t3,t4,dens,dal,dlim
DOUBLE PRECISION di1,di2,di3,di4

IF (t3.ge.0.0) THEN [1]
di3=(t3*d1-xx)**2+(t3*d2-yy)**2+(t3*d3-zz)**2 [2]
ELSE [3]
di3=999.9 [4]
ENDIF [5]
========================
I am seeing floating point overflow error at line [2].

Any Idea, what could be wrong here?

FYI, I tried /heap-array compiler option on Linux platform with same source and with debug build, I did not see any crash.

Thanks for your help.

-Vipin

[jimdempseyatthecove]

Vipin,

>> di3=(t3*d1-xx)**2+(t3*d2-yy)**2+(t3*d3-zz)**2

Although di3 is double precision, the components on the right side of = are all single precision. The expression is not promoted to double precision until after it is evaluated.

Promote explicitly

di3=(dble(t3)*dble(d1)-dble(xx))**2+(dble(t3)*dble(d2)-dble(yy))**2+(dble(t3)*dble(d3)-dble(zz))**2

This should work as well

di3=(dble(t3)*d1-xx)**2+(dble(t3)*d2-yy)**2+(dble(t3)*d3-zz)**2

As the others _should_ be promoted as well.

Jim Dempsey