Discussion :

[hamskat]

Bonjour à tous.

J'ai eu du mal à choisir la rubrique adaptée, désolée si jamais ce n'est pas la bonne.

Voilà mon problème. J'ai un programme en C qui fait à un moment donné appel soit à une méthode écrite en C, soit à une routine équivalente en fortran (d'une lib externe).

Aux deux, je passe un pointeur vers un tableau de flottants, elles mettent à jour certaines valeurs dans ce tableau.

Le run avec l'appel à la méthode en C passe, les résultats sont OK. Le run avec l'appel à la routine fortran plante. Le programme est compilé en mode debug. Si je lance valgrind dessus, le programme tourne jusqu'au bout, pas d'erreur signalée à proximité de la "zone sensible". D'autres erreurs sont, on va dire, connues et inévitables (mpi et l'interface python générée automatiquement). De même avec Totalview - déroulement sans accroc jusqu'au bout.

Je sais qu'il y a une différence entre les programmes compilées en optimisé et ceux compilés en debug. Mais là c'est le même, juste lancé directement ou via un debuggeur.

Je ne comprends pas comment ça peut arriver et surtout, dans quelle direction chercher. Les print dans fortran arrivent pas trop dans l'ordre mais c'est pratiquement sûr que c'est au moment de mettre à jour le tableau passé en argument que ça plante. Je peux me débrouiller pour flusher l'output du programme pour en être sûre mais bon, ça ne m'avancera pas beaucoup.

Any hint, même un "RTFM (ici)" serait le bienvenu. Ma question principale c'est comment ça peut arriver que le même programme tourne sous un debugger et pas seul. Et quel autre piste je pourrais envisager.

P.S. Le code est gros, j'aurais du mal à en isoler une partie utilisable pour poster ici, mais si jamais c'est vraiment nécessaire...

[gangsoleil]

Bonjour,

L'ordre de gestion des cases memoires d'un tableau en C et en Fortran n'est pas la meme : le C gere d'abord les lignes, puis les colonnes, alors que le Fortran fait l'inverse (je parle ici des representations memoires des tableaux)

En C :

Code :

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

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

En Fortran :

Code :

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

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

Est-ce que votre probleme ne pourrait pas venir de la ?

[hamskat]

Oui, ça je le sais et normalement je gère ceci correctement (ce n'est pas la première fois que je fais appel à une routine fortran depuis C et d'habitude tout se passe bien). Si ce n'était pas le cas, les résultats (obtenus par un run via un debugger) seraient faux.

Ça sent vraiment un problème mémoire quelque part sauf que malheureusement je ne sais pas comment l'isoler.

[Obsidian]

Il faudrait que tu nous dises sur quelle plate-forme tu travailles, déjà, et quels outils tu utilises. Le message d'erreur exact nous aiderait beaucoup également : on ne sait même pas encore de quelle erreur il s'agit (segfault ?).

Sinon, formellement, les bugs intermittents proviennent généralement de grandes classes d'événements :

— Les race conditions ;
— Les dépassements de tableau.

En dehors de celles-ci, on peut chercher ensuite du côté des effets de bords, et des changements inopinés d'environnement ou de configuration.

Il est tout-à-fait possible, donc, et par exemple, que ta fonction dépasse légèrement la taille du tableau, ce qui dans le cas du programme en fonctionnement normal, reste dans le segment de mémoire qui lui est alloué, et que ça dépasse dans le cas du déboggueur parce que celui organise les données différemment, pour pouvoir ajouter les siennes. C'est assez classique.

[hamskat]

Oui c'est vrai, pardon. J'aurais dû donner ces informations dès le début.

Je suis sous Linux 2.4.21-32.ELsmp GNU/Linux, je compile avec pgi version 6.0 (oui, je sais mais je n'ai pas le choix).

Et il n'y a aucun message d'erreur, ça s'arrête net. J'aurais bien aimé voir le stack mais l'option "-tracestack" n'est même pas disponible sur cette version de compilateur

J'ai quand-même vérifié le code d'erreur ($?), c'est 130:

Exit code 130: The job ran out of CPU or swap time. If swap time is the culprit, check for memory leaks.

Merci, c'est un bon réflexe à prendre que je n'ai pas encore.

Je vais voir ce que c'est les race conditions et je reviens.

[Obsidian]

Tu débugues avec quoi ? Avec un débugueur intégré à ton compilateur ?

À part ça, utilises-tu des fonctions récursives ou, au moins réentrantes ?

Sinon, enfin, quelle taille font tes tableaux ? Il est assez courant de voir des débutants déclarer comme des variables locales des tableaux de plusieurs méga-octets, sans savoir que celles-ci sont instanciées dans la pile. C'est un cas courant de stack overflow.

[hamskat]

Tu débugues avec quoi ? Avec un débugueur intégré à ton compilateur ?

Si je lance valgrind dessus, le programme tourne jusqu'au bout, pas d'erreur signalée à proximité de la "zone sensible". De même avec Totalview - déroulement sans accroc jusqu'au bout.

À part ça, utilises-tu des fonctions récursives ou, au moins réentrantes ?

Non, du tout. C'est une routine tout con, en gros ça fait quelque chose comme (nous avons défini une surcouche pour les arrays, donc poster du vrai code n'aurait pas trop de sens)

Code :

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

1
2
3
4
int n = 10;
déclaration/allocation d un tableau T de taille n;
int i = 1; // premier élément du tableau correspondant au T[0], c'est bien ça?
routine_(&n, &i, &(T[0]));

puis dans fortran

Code :

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

1
2
3
4
5
6
7
subroutine routine(n, i, t)
integer i, n
real*8  t(n)
real*8 x
x = ... calcul avec les variable locales ...
t[i] = x
end

Sinon, enfin, quelle taille font tes tableaux ? Il est assez courant de voir des débutants déclarer comme des variables locales des tableaux de plusieurs méga-octets, sans savoir que celles-ci sont instanciées dans la pile. C'est un cas courant de stack overflow.

Dans le cas où ça plante (parce que l'appel se fait plusieurs fois, avec de tableaux différents et le plantage ne survient pas toujours), il contient 19110 double floats, ça ne me paraît pas énorme.

Est-ce que le fait de passer trois pointeurs vers trois endroits différents de ce même tableau peut jouer? En fait, c'est un tableau de coordonnées organisé comme [x1 x2 x3 ... y1 y2 y3 ... z1 z2 z3 ...] et la routine est faite de manière à prendre en entrée trois tableaux, donc je lui passe les pointeurs vers x1, y1 et z1... Le code serait doc plutôt:

Code :

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

1
2
3
4
int n = 6; // pour décrire deux points: [x1 x2 y1 y2 z1 z2]
déclaration/allocation d un tableau T de taille n;
int i = 1; // je veux modifier les xyz correspondant au premier point dans la liste, et comme fortran parcourt ses tableaux de 1 à n...
routine_(&n, &i, &(T[0]), &(T[2]), &(T[4]));

et

Code :

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

1
2
3
4
5
6
7
8
9
10
11
subroutine routine(n, i, tx, ty, tz)
integer i, n
real*8  tx(n), ty(n), tz(n)
real*8 x, y, z
x = ... calcul avec les variable locales ...
y = ... calcul avec les variable locales ...
z = ... calcul avec les variable locales ...
tx[i] = x
ty[i] = y
tz[i] = z
end

[hamskat]

Est-ce que le fait de passer trois pointeurs vers trois endroits différents de ce même tableau peut jouer?

C'est tout comme. Si je crée trois tableaux différents X, Y et Z, y copie les données depuis le tableau XYZ, et passe les trois en argument, ça fonctionne. Mais suis-je vraiment obligée de passer par cette copie ou c'est juste que je m'y prends comme une manche avec le tableau unique?