Discussion :

[melreg]

Bonjour,

Après un passage dans ce forum, je n'ai pas trouvé de post sur une telle erreur. J'espère ne pas m'attirer les foudres des utilisateurs, mais c'est vraiment compliqué pour moi de donner un exemple minimal ici... je vous explique mon problème, en espérant le décrire suffisamment:

Dans mon programme, j'appelle une routine. L'erreur donnée dans le titre de mon post survient à l'exécution juste après son appel (rien n'est exécuté à l'intérieur de cette dernière et un print juste avant me certifie que l'erreur est là).
Comme l'indique l'erreur, j'ai regardé la taille des arguments passé à ma routine: pas de pointeur de taille négative (tous mes arguments sont des vecteurs(=pointeurs déjà alloués sans problème avant) de taille notamment 59120, 29954, 177360).
Est-ce que le problème peut venir du fait qu'ils soient trop grands?

La compilation (à l'aide de gfortran version 4.3) se fait sans problème, c'est bien à l'exécution que l'erreur survient. De plus, en cherchant sur le net, j'ai trouvé qu'il y avait un bug dans gfortran affichant cette erreur... mais il me semble que cela fait référence à la version 4.1).

Pensez-vous à une option de compilation qui pourrait m'en dire plus? Actuellement, je compile avec les options:
-c -C -fbounds-check

EDIT: Si je fais tourner mon programme avec d'autres valeurs (qui induisent des tailles de vecteurs plus petites, ça marche...)

Merci d'avance.

[Grame]

Est-ce que le problème peut venir du fait qu'ils soient trop grands?

Ca me semble une bonne piste puisque

Si je fais tourner mon programme avec d'autres valeurs (qui induisent des tailles de vecteurs plus petites, ça marche...)

Il est possible (probable ?) que la taille à allouer pour le tableau dépasse la taille de la mémoire physique de la machine.

Un bon test serait d'exécuter le même code sur une autre machine ayant davantage de mémoire.

[genteur slayer]

si tu as la possiblité de modifier les tailles une par une, cherche sur quel tableau cela merdouille... de plus ce ne sont pas les tab que tu "envoie" à ta fonction qui ne marchent pas mais plutôt ceux déclarer localement à ta routine...
je commencerai à chercher de ce coté...
la taille de tes tableau ne me semble pas à priori démesurée je doute que ce soit ça le pb, en revanche modifier les tailles peut conduire à ce que tu tombe dans le cas particulier où tout marche...

[melreg]

si tu as la possiblité de modifier les tailles une par une, cherche sur quel tableau cela merdouille...

A priori pas si facilement, mais je vais essayer...

de plus ce ne sont pas les tab que tu "envoie" à ta fonction qui ne marchent pas mais plutôt ceux déclarer localement à ta routine...
je commencerai à chercher de ce coté...

Je ne comprends pas bien... je ne suis pas calé dans ce domaine, mais comment est-ce possible que ce soit la déclaration dans ma routine qui ne marche pas? Etant donné qu'avec de petits tableaux, ça joue?

Sinon, je ne pense pas non plus que ça soit la mémoire de mon ordinateur qui ne soit pas assez conséquente: il est relativement récent et surtout, ce programme n'a pas l'air de demander tant. D'ailleurs en regardant dans le moniteur système (je suis sur ubuntu), je vois que ma mémoire est utilisé au max à 60%...

Dernier détail... en mettant d'autres paramètres faisant également intervenir de "grandes" tailles de tableaux (je mets grande entre guillemets car ça reste tout de même des tableaux d'une dimension avec nettement moins d'un milion de composantes), j'obtiens une erreur de segmentation...

Bref, je patauge...

Merci encore une fois.

[JeitEmgie]

…Comme l'indique l'erreur, j'ai regardé la taille des arguments passé à ma routine: pas de pointeur de taille négative (tous mes arguments sont des vecteurs(=pointeurs déjà alloués sans problème avant) de taille notamment 59120, 29954, 177360).
…

Possible piste :

59120 > 32767, le plus grand entier positif codé sur 16 bits…
59120 = -6416 quand la quantité est codée sur un entier 16 bits…

vérifiez donc le type des entiers qui contiennent les tailles des tableaux…
et s'il n'y a pas de conversion en entier 16 bits "dans votre dos"…

[melreg]

J'ai toujours entré

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

integer

sans préciser le nombre de bits utilisés. Pour mettre en 16bits la taille d'un vecteur, comment faire?

[JeitEmgie]

J'ai toujours entré

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

integer

sans préciser le nombre de bits utilisés. Pour mettre en 16bits la taille d'un vecteur, comment faire?

pas en 16 bits… en 32 bits… (minimum) !

les variables qui définissent/contiennent les tailles des vecteurs devraient donc être des LONG INTEGER…

(enfin… de mémoire… c'est loin le FORTRAN…)

c'est quand même curieux qu'ayant mis INTEGER, le compilateur aurait choisi des SHORT INTEGER …
donc c'est peut-être pas çà le problème… à moins que ce soit un effet de bord qu'un flag de compilation…

enfin, ne perdez pas de vue que le message d'erreur puisse être farfelu par rapport à la vraie nature du problème… c'est sans doute lié à l'allocation des tableaux, mais çà pourrait aussi être la taille totale qui soit trop importante…

le message faisant allusion à une valeur négative, il est juste raisonnable de penser que ce soit une histoire d'overflow d'entier signé…

[genteur slayer]

ou bien utilisé le paramètre kind:
(seulement pour veersion de fortran >=90 )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

integer(kind=4) :: <var>

tu lui dit de coder l'entier sur 4 octets 4*8=32bits... il dois y avoir une option pour dire signé ou non...

[melreg]

Re-bonjour,

J'ai essayé ce que vous m'avez suggéré... sans succès. Explications:
- j'ai compilé avec l'option -i4 ce qui signifie que tout entier rencontré est codé sur 4 octets =32 bits. Egalement avec -i8 pour 8 octets. Mais ça ne change rien... en fait, par défaut, un entier est codé sur 4 bits en fortran 90.
et pour rappel, les tailles de mes tableaux ne dépassent pas 6*221586= 1,329,516 ce qui est loin de la borne supérieure d'un entier codé sur 32bits qui est de 2,147,483,647...

- je ne crois pas qu'on puisse initialiser un entier non signé en fortran 90... du coup, je n'ai pas pu essayer cette alternative.

En cherchant sur le net, j'ai trouvé ce sitehttp://docs.hp.com/en/B3909-90002/ch08s01.html, et plus particulièrement ce passage:

An unsigned integer in C can represent twice the number of positive values as the same-sized integer in HP Fortran 90. If an HP Fortran 90 program calls a C function that returns an unsigned integer and the return value is greater than can be represented in a signed integer, HP Fortran 90 will interpret the bit pattern as a negative number.

Cela expliquerait peut-être l'histoire de la "negative amount"... (je ne sais pas si ça a son importance, mais mon ordi est un hp).

Je cherche toujours de mon côté. N'hésitez pas à me donner de l'aide... j'en ai fichtrement besoin...
Merci d'avance.

[genteur slayer]

HP signifie un type de machine, si tu es sur PC même de marque HP, ce message ne te concerne pas...
en revanche,

tu peux tester avec une routine vide (sans aucune déclaration ou opération à l'intérieur) ce qui te dira immédiatement si le problème viend de l'appel de la routine ou de ce qu'il y a à l'intérieur...
ensuite tu peux utiliser la fonction allocate plutôt que de donner des tailles fixes, cela permetra d'afficher mieux les erreurs éventuelles...