Take the 2-minute tour ×

Using identical source files for a FORTRAN .dll I can compile them with Compaq Visual Fortran 6.6C or Intel Visual Fortran (IA-32). The problem is that the execution fails on the Intel binary, but works well with Compaq. I am compiling 32-bit on a Windows 7 64-bit system. The .dll calling driver is written in C#.

The failure message comes from the dreaded _chkstk() call when an internal subroutine is called (called from the .dll entry routine). (SO answer on chkstk())

The procedure in question is declared as (pardon the fixed file format)

  SUBROUTINE SRF(den, crpm, icrpm, inose, qeff, rev,  
 &               qqmax, lvtyp1, lvtyp2, avespd, fridry, luin,  
 &               luout, lurtpo, ludiag, ndiag, n, nzdepth, 
 &               unit, unito, ier)

  INTEGER*4 lvtyp1, lvtyp2, luin, luout, lurtpo, ludiag, ndiag, n, 
 &          ncp, inose, icrpm, ier, nzdepth
  REAL*8    den, crpm, qeff, rev, qqmax, avespd, fridry           
  CHARACTER*2  unit, unito

and called like this:

      CALL SRF(den, crpm(i), i, inose, qeff(i), rev(i),  
 &             qqmax(i), lvtyp1, lvtyp2, avespd, fridry, 
 &             luin, luout, lurtpo, ludiag, ndiag, n, nzdepth,  
 &             unit, unito, ier)

with similar variable specifications except for crpm, qeff, rev and qqmax are arrays of which only the i-th elements is used for each SRF() call.

I understand possible stack issues if the arguments are more than 8kb in size, but in this case we have 7 x real(64) + 11 x int(32) + 2 x 2 x char(8) = 832 bits only in passed arguments.

I have worked really hard to move arguments (especially arrays) into a module, but I keep getting the same error


The dissasembly from the intel .dll is


The dissasembly from the compaq .dll is


Can anyone offer any suggestions on what is causing the SO, or how to debug it?

PS. I have increased the reserved stack space to hundreds of Mb and the problem persists. I have tried skipping the chkstk() call in the dissasembler but in crashes the program. The stack check starts from address 0x354000 and iterates down to 0x2D2000 where it crashes accessing a guard page. The stack bottom address is 0x282000.

share|improve this question
What compiler options are you using in each case? Try compiling will all the warning error flags you can think of enabled. As a first step I tend to use -std -check all -Warn all,nodec,interfaces,declarations -gen_interfaces -g -C -traceback -fpe0 -fp-stack-check with ifort. –  Chris Apr 14 '12 at 12:01
I expect you've spotted your own arithmetic mistake by now, but your total of 832 bytes should be 832 bits. It's not always the case, either, that each character is represented by one byte: this tends to vary with compiler and platform. With an up to date compiler the size of the various 'storage units' are available as constants defined in ISO_FORTRAN_ENV intrinsic module. –  High Performance Mark Apr 14 '12 at 18:27
Both comments above give me something to work with. I will investigate more. It is possible there is a stack corruption that CVF is not catching and somehow blows over it. There is a lot going on in the code as many developers have touched it since the 80's when it was first written. –  ja72 Apr 15 '12 at 19:19
As an update none of the tricks and changes I have tried so far have gotten me any closer to a resolution. I have reduced the number and size of parameters down to like 8 scalars and the problem persist. –  ja72 Jun 3 '12 at 2:30
_chkstk() checks for enough stack space for local variables, not for arguments (they are already in the stack). Do you by and chance have large arrays local to the subroutine? Intel Fortran doesn't do heap allocation of local arrays by default. –  Hristo Iliev Jun 5 '12 at 14:49

1 Answer 1

You are shooting the messenger. The Compaq generated code also calls _chkstk(), the difference is that it inlined it. A common optimization. The key difference between the two snippets is:

 mov eax, 0D3668h


 sub esp, 233E4h

The values you see used here are the amount of stack space required by the function. The Intel code requires 0xd3668 bytes = 865869 bytes. The Compaq code requires 0x233e4 = 144356. Big difference. In both cases that's rather a large amount but the Intel one is getting critical, a program normally has a one megabyte stack. Gobbling up 0.86 megabytes of it is pushing it very close, nest a couple of functions calls and you're looking at this site's name.

What you need to find out, I can't help because it is not in your snippet, is why the Intel generated function needs so much space for its local variables. Workarounds are to use the free store to find space for large arrays. Or use the linker's /STACK option to ask for more stack space (guessing at the option name).

share|improve this answer
Thanks for the info. Can you elaborate on use the free store to find space? There are a lot of computations that happen in this array, filling an array of 18,000,000 elements of REAL*8. –  ja72 Jun 9 '12 at 18:39
I'm pretty old but not quite old enough. Look at the ALLOCATE and DEALLOCATE statements in your favorite Fortran reference. –  Hans Passant Jun 9 '12 at 18:46
These arrays are allocated in VBA and passed to the Fortran .dll. They are not allocated in Fortran, so I cannot use allocatable arrays. The posting has been very helpful though, as I am still looking for an answer here. –  ja72 Nov 5 '13 at 17:15

Your Answer


