Overflow de pile en fortran 90

Tous les mots ne sont pas créés lorsque le programme commence. Lorsque vous appelez le sous-programme, l'exécutable crée la mémoire dont le sous-programme a besoin de variables locales. Généralement des tableaux avec des déclarations simples locales à ce sous-programme - ni allouatable, ni pointeur - ne sont attribués sur la pile. Vous auriez pu simplement gérer de l'espace de pile lorsque vous avez atteint ces déclarations. Vous avez peut-être atteint une limite de 2 Go sur un système d'exploitation 32 bits avec un tableau. Parfois, des déclarations exécutables créent implicitement un tableau temporaire sur la pile.

Solutions possibles: 1) Faites de vos matrices plus petites (non attrayantes), 2) Faire la pile plus grande), 3) Certains compilateurs ont des options pour passer de tableaux de placement sur la pile pour les affecter de manière dynamique, similaire à la méthode utilisée pour "Allouer", 4) Identifiez les grandes matrices et les rendre allocalisables.

Utilisez-vous une certaine parallélisation? Cela peut être un problème avec des tableaux déclarés statiquement. Essayez tous les raies plus gros rendent allouatable, sinon, ils seront placés sur la pile en fils autoparallel ou openmp.

Selon la demande de SteaSbert, je vais simplement résumer la conversation dans les commentaires ici où il est un peu plus visible, même si la réponse de M.S.B. est déjà dûment droit à la nuit du problème.

Dans la programmation technique, où les procédures ont souvent de grandes matrices locales pour le calcul intermédiaire, cela se produit beaucoup. Les variables locales sont généralement stockées sur la pile, qui typiquement (et assez raisonnablement) une petite fraction de la mémoire globale du système - généralement d'ordre 10MB environ. Lorsque les tailles de variables locales dépassent la taille de la pile, vous voyez exactement les symptômes décrits ici - un débordement de pile survenu après un appel au sous-programme concerné, mais avant sa première déclaration exécutable.

Ainsi, alors que ce problème se produit, La meilleure chose à faire est de trouver les grandes variables locales pertinentes et de décider quoi faire. Dans ce cas, au moins les variables BELM et DStrain deviennent assez importantes.

Une fois que les variables sont localisées et que vous avez confirmé que c'est le problème, il y a quelques options. Comme MSB souligne, si vous pouvez rendre vos matrices plus petites, c'est une option. Alternativement, vous pouvez faire la taille de la pile plus grande; Sous Linux, cela est fait avec ulimit -s [Newsize] . Cela ne fait que reporter simplement le problème, cependant, et vous devez faire quelque chose de différent sur les machines Windows.

L'autre classe de manières d'éviter ce problème n'est pas de mettre les grandes données sur la pile, mais dans le reste de mémoire (le "tas"). Vous pouvez le faire en donnant aux tableaux l'attribut enregistrez (en C, statique ); Cela met la variable sur le tas et rend ainsi les valeurs persistantes entre les appels. L'inconvénient est que cela modifie potentiellement le comportement du sous-programme et signifie que le sous-programme ne peut pas être utilisé de manière récursive et non de non-threadsafe (si vous êtes dans une position dans laquelle plusieurs threads entreront dans la routine simulatne, elles On voit chacun la même copie de la varaitable locale et potentiellement écrasé les résultats de chacun). L'avantage est que c'est facile et très portable - il devrait fonctionner partout. Cependant, cela ne travaillera que avec des variables locales de taille fixe; Si les matrices temporaires ont des tailles qui dépendent des entrées, vous ne pouvez pas le faire (car il n'y avait plus une seule variable à enregistrer; il pourrait être une taille différente chaque fois que la procédure est appelée). < p> Il existe des options spécifiques au compilateur qui mettent toutes des tableaux (ou tous les tableaux de taille supérieure à une taille donnée) sur le tas plutôt que sur la pile; Chaque compilateur de Fortran que je connais a une option pour cela. Pour IFORT, utilisé dans la POST OPS, c'est -heap-tableaux sous Linux ou / tas de tas pour Windows. Pour gfortran, cela peut en réalité être la valeur par défaut. C'est bon pour vous assurer de savoir ce qui se passe, mais cela signifie que vous devez avoir des incantations différentes pour chaque compilateur pour vous assurer que votre code fonctionne.

Enfin, vous pouvez faire des matrices incriminées allouées. La mémoire allouée va sur le tas; Mais la variable qui leur pointe est sur la pile, vous bénéficiez donc des avantages des deux approches. En outre, cela est complètement standard pourtran et donc totalement portable. L'inconvénient est que cela nécessite des changements de code. En outre, le processus d'attribution peut prendre des quantités non triviales; Donc, si vous allez appeler les zillions de routine de fois, vous remarquerez peut-être que cela ralentit légèrement les choses. (Cette éventuelle régression de la performance est facile à corriger, cependant; si vous l'appelez des zillions de fois avec les matrices de même taille, vous pouvez avoir un argument facultatif pour passer dans un tableau local pré-alloué et utiliser cela, de sorte que Vous n'allouez que tous seulement).

alloué / trafiquant chaque fois ressemblerait à: xxx

Notez que si le sous-programme fait beaucoup de travail (par exemple, prend des secondes à exécuter), Les frais généraux d'un couple allouent / trafiquant devraient être négligables. Sinon, et vous voulez éviter les frais généraux, l'utilisation des arguments facultatifs de PrealloCated Womanpace ressemblerait à quelque chose comme: xxx