Переполнение стека в Fortran 90

я написал довольно большую программу в Fortran 90. Он работает красиво довольно долго, но сегодня я попытался поднять его на ступеньку и увеличить размер проблемы (это исследование нестандартного Fe-решателя, если это кому-то поможет...) Теперь я получаю сообщение об ошибке "переполнение стека", и, естественно, программа завершается, не давая мне ничего полезного для работы.

программа начинается с настройки всех соответствующих массивов и матриц, и после этого это делается печатает несколько строк статистики относительно этого в файл журнала. Даже с моей новой, большей проблемой это работает нормально (хотя и немного медленно), но затем это терпит неудачу, поскольку "число хрустит".

что меня смущает, так это то, что все в этот момент уже выделено (и это работало без ошибок). Я не совсем уверен, что такое стек (Википедия и несколько протекторов здесь не сделали многого, так как у меня есть только довольно базовые знания о "закулисных" работах компьютер.)

предположим, что у меня, например, есть некоторые массивы, инициализированные как:

INTEGER,DIMENSION(64) :: IA
REAL(8),DIMENSION(:,:),ALLOCATABLE :: AA, BB

которые после некоторых процедур инициализации (т. е. чтения ввода из файла и т. д.) выделяются как (я храню некоторые целые числа размера для более легкого перехода к подпрограммам в IA фиксированного размера):

ALLOCATE( AA(N1,N2) , BB(N1,N2) )
IA(1) = N1
IA(2) = N2

это в основном то, что происходит в начальной части, и до сих пор так хорошо. Но когда я тогда Вызываю подпрограмму

CALL ROUTINE_ONE(AA,BB,IA)

и процедура выглядит так (ничего особенного):

SUBROUTINE ROUTINE_ONE(AA,BB,IA)
IMPLICIT NONE
INTEGER,DIMENSION(64) :: IA
REAL(8),DIMENSION(IA(1),IA(2)) :: AA, BB
...
do lots of other stuff
...
END SUBROUTINE ROUTINE_ONE

теперь я получаю ошибку! Вывод на экран говорит:

forrtl: severe (170): Program Exception - stack overflow

однако, когда я запускаю программу с отладчиком, она ломается в строке 419 в файле с именем winsig.c (Не мой файл, но, вероятно, часть компилятора?). Кажется, это часть рутины под названием sigreterror: и это дело по умолчанию, который был вызван, возвращая текст Invalid signal or error. К этому прилагается строка комментария, которая странно говорит /* should never happen, but compiler can't tell */ ...?

так что я думаю, мой вопрос, почему это происходит и что на самом деле происходит? Я думал, что пока я могу выделить всю соответствующую память, я должен быть в порядке? Делает ли вызов подпрограммы копии аргументов или просто указывает на них? Если ответ-копии, тогда я вижу, где может быть проблема, и если да, то какие-нибудь идеи о том, как ее обойти?

проблема, которую я пытаюсь решить, большая, но никак не безумная. Стандартные Fe-решатели могут справляюсь с большими проблемами, чем моя нынешняя. Я запускаю программу на Dell PowerEdge 1850, а ОС-Microsoft Server 2008 R2 Enterprise. Согласно systeminfo на cmd подсказка у меня есть 8 ГБ физической памяти и почти 16 ГБ виртуальной. Насколько я понимаю, общая сумма всех моих массивов и матриц не должна составлять более 100 МБ - около 5,5 м integer(4) и 2,5 м real(8) (что, по моему мнению, должно быть только около 44 Мб, но давайте будем справедливы и добавим еще 50 МБ для надземный.)

я использую компилятор Intel Fortran, интегрированный с Microsoft Visual Studio 2008.

добавление фактического исходного кода для уточнения немного

! Update continuum state
CALL UpdateContinuumState(iTask,iArray,posc,dof,dof_k,nodedof,elm,&
                    bmtrx,detjac,w,mtrlprops,demtrx,dt,stress,strain,effstrain,&
                    effstress,aa,fi,errmsg)

является фактическим вызовом в рутину. Большие массивы posc, bmtrx и aa - все остальные, по крайней мере на порядок меньше (если не больше). posc is INTEGER(4) и bmtrx и aa и REAL(8)

SUBROUTINE UpdateContinuumState(iTask,iArray,posc,dof,dof_k,nodedof,elm,bmtrx,&
                    detjac,w,mtrlprops,demtrx,dt,stress,strain,effstrain,&
                    effstress,aa,fi,errmsg)

    IMPLICIT NONE

    !I/O
    INTEGER(4) :: iTask, errmsg
    INTEGER(4) :: iArray(64)
    INTEGER(4),DIMENSION(iArray(15),iArray(15),iArray(5)) :: posc
    INTEGER(4),DIMENSION(iArray(22),iArray(21)+1) :: nodedof
    INTEGER(4),DIMENSION(iArray(29),iArray(3)+2) :: elm
    REAL(8),DIMENSION(iArray(14)) :: dof, dof_k
    REAL(8),DIMENSION(iArray(12)*iArray(17),iArray(15)*iArray(5)) :: bmtrx
    REAL(8),DIMENSION(iArray(5)*iArray(17)) :: detjac
    REAL(8),DIMENSION(iArray(17)) :: w
    REAL(8),DIMENSION(iArray(23),iArray(19)) :: mtrlprops
    REAL(8),DIMENSION(iArray(8),iArray(8),iArray(23)) :: demtrx
    REAL(8) :: dt
    REAL(8),DIMENSION(2,iArray(12)*iArray(17)*iArray(5)) :: stress
    REAL(8),DIMENSION(iArray(12)*iArray(17)*iArray(5)) :: strain
    REAL(8),DIMENSION(2,iArray(17)*iArray(5)) :: effstrain, effstress
    REAL(8),DIMENSION(iArray(25)) :: aa
    REAL(8),DIMENSION(iArray(14)) :: fi 

    !Locals
    INTEGER(4) :: i, e, mtrl, i1, i2, j1, j2, k1, k2, dim, planetype, elmnodes, &
        Nec, elmpnodes, Ndisp, Nstr, Ncomp, Ngpt, Ndofelm
    INTEGER(4),DIMENSION(iArray(15)) :: doflist
    REAL(8),DIMENSION(iArray(12)*iArray(17),iArray(15)) :: belm
    REAL(8),DIMENSION(iArray(17)) :: jelm
    REAL(8),DIMENSION(iArray(12)*iArray(17)*iArray(5)) :: dstrain
    REAL(8),DIMENSION(iArray(12)*iArray(17)) :: s
    REAL(8),DIMENSION(iArray(17)) :: ep, es, dep
    REAL(8),DIMENSION(iArray(15),iArray(15)) :: kelm
    REAL(8),DIMENSION(iArray(15)) :: felm

    dim       = iArray(1)
...

и он терпит неудачу перед последней строкой выше.