Attempt to allocate a negative amount of memory

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.

Citation:

---

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

---

Ca me semble une bonne piste puisque

Citation:

---

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.

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...

Citation:

---

Envoyé par genteur slayer

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...

Citation:

---

Envoyé par genteur slayer

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.

Citation:

---

Envoyé par melreg

…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"…

J'ai toujours entré

Code:

---

integer

---

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

Citation:

---

Envoyé par melreg

J'ai toujours entré

Code:

---

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é…

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

Code:

---

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...

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.

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...

Merci pour ta réponse genteur slayer.

J'ai du nouveau: le problème vient d'un tableau défini à l'intérieur de ma routine (et non pas un de ses arguments). Sa taille est de n x n où n vaut 37370, ce qui fait 1'396'516'900 entrées. C'est vrai que c'est grand... mais ça reste toujours plus petit que la borne supérieur pour un entier codé sur 32 bits (ce qui est mon cas) qui est de 2'147'483'647...

Encore du nouveau.

Je déclare mon tableau "allocatable". Puis, je l'alloue

Code:

---

allocate(tab(1:n,1:n))

---

Ensuite, je l'initialise à 0

Code:

---

tab=0

---

C'est là que le problème survient. Il n'arrive pas à effectuer cette initialisation, et cette fois, le message d'erreur est:

Fortran runtime error: Attempt to allocate negative amount of memory. Possible integer overflow

Comment faire? En regardant le posthttp://www.developpez.net/forums/d51...male-tableaux/, J-M Blanc a l'air de dire que ce n'est pas la mémoire de l'ordinateur qui pose problème...

Qu'en pensez-vous?

Ton tableau est effectivement trop gros. Tu ne dois pas le voir en nombre d'éléments, mais en nombre d'octets.

Comme ton tableau est en integer (4), il occupe 37370 x 37370 x 4 = 5 586 067 600, ce qui dépasse 2 147 xxx xxx. Même si la taille était était traitée comme unsigned, ça ne marcherait pas.

Si tu as vraiment besoin de cette taille, tu dois utiliser un SE 64 bits et un compilateur 64 bits, ou changer ton algorithme...

Merci Sylvain pour ta réponse. En y réfléchissant, je me demande si ce n'est pas plutôt la taille de ma RAM qu'il faut considérer?... comme elle est de 3Gio et que 37370 x 37370 x 4 = 5 586 067 600 > 3Go, il y a un problème. De plus, je ne pouvais pas coder mes entiers sur 2 octets car dans ce cas, ma borne supérieur est de 32 *** et j'entrais des nombres jusqu'à 37370 (justement).

Bref, je me résous à modifier mon code (ce qui n'est pas plus mal finalement...).

Encore merci à tous pour vos réponses.

souvent dans ce genre de tableaux gigantesques, beaucouop de valeures ne sont pas significatives... regarde donc des cours/articles sur le stokage creux, stokage par lignes de ciels etc..

de plus, si ta machine dépasse 4Go (et des poussières) de RAM un système 64bits est obligatoire pour addressé toute ta RAM et donc un compilo 64bit pour pouvoir l'utiliser!!!

en gros allocate ne te renvoie pas d'érreur directement, il crée un pointeur vers le début du tableau et cherche à réservé autant de mémoire qu'il peut... en revanche lorsque tu affecte une valeur, le système cherche à écrire dans une zone qui n'existe pas et donc->erreur...

Bonjour,

Citation:

---

Envoyé par genteur slayer

en gros allocate ne te renvoie pas d'érreur directement, il crée un pointeur vers le début du tableau et cherche à réservé autant de mémoire qu'il peut... en revanche lorsque tu affecte une valeur, le système cherche à écrire dans une zone qui n'existe pas et donc->erreur...

---

En es-tu bien sûr? Il me semble qu'au contraire le allocate() gère ce genre d'erreur, mais encore faut-il prendre le soin de vérifier que l'allocation s'est correctement déroulée, à l'aide de l'argument (optionel) stat:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

integer :: ok,n real,allocatable :: tab(:,:)   ....   allocate(tab(1:n,1:n),stat=ok) if (ok==0) then write(*,*) "Allocation de tab:,:) OK" else write(*,*) "Probleme lors de l'allocation de tab(1:n,1:n), n=",n endif

---

En effet genter slayer, ma matrice était creuse... j'ai pu modifier mon code pour libérer de la mémoire et ça joue maintenant. En fait, pour me faire pardonner cette partie du code ne venait pas de moi... mais c'est vrai que j'aurais du remarquer avant que la matrice était creuse...

En tout cas, merci à tous. Concernant la nouvelle discussion qui a pris forme sur ce post, je ne suis pas assez calé... mais content que ça titille votre curiosité!

il y a évidement plusieur argument optionnel de allocate!!! mais lorsque l'on ne s'en sert pas, il n'y a pas d'érreur retournée...

aujourd'hui, on a tendance à ne plus se soucier de la place mémoire, les machines ayant souvent beaucoup de mémoire, mais dans les temps anciens de l'informatique (jolie expression) c'était ce qui comptais le plus: on raisonnait presque octets par octets (évidement il n'y en avais très peu) cepandant, encore aujourd'hui il faut pensé que l'ion a certaines limites qu'il ne faut pas dépasser.

on dit souvent qu'il y a une formule pour un même code:
<place mémoire>*<nombre de calcul>=constante
donc en gros (c'est schématique) mais si tu optimise ta mémoire, tu augmente le nombre de calcul, l'idée c'est d'avoir un compromi entre les deux... (bien évidement, je simplifie énormément)