Discussion :

[dva2tlse]

Bonjour le forum; j'ai déjà posé sur ce forum des questions relatives au développement que j'ai à faire. C'est un gros programme en fortran, enfin gros pour moi en tous cas, qui ne suis pas du tout développeur mais ingénieur mécanicien, et le problème qui se pose à moi est que lors de la lecture d'un des fichiers d'entrée, il se produit l'erreur suivante :

Code :

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

1
2
At line 2189 of file /S/DATA/DVA/F90/BN/p2srfd.f
Fortran runtime error: Bad value during integer read

C'est une banale lecture dans une variable indicée comme il y en a des dizaines d'autres :

Code :

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

read(MDana(Tana), '(I1, I1)') Mana, Dana

Pour ceux qui ne parlent pas le fortran, ça vaut dire qu'on lit dans la variable MDana(Tana); c'est une chaine de deux caractères issue du fichier d'entrée, et chacun est interprété comme un entier, pour remplir les variables entières Mana et Dana.
(il y a cinq fichiers d'entrée, un seul de sortie, et quelques autres temporaires ou d'entrées facultatives selon les options choisies)

En essayant avec un autre fichier d'entrée, qui est lu et dont les deux millions de lignes pour le plus long, sont mises en mémoire dès le début du programme, il se produit la même erreur au même endroit et je ne la vois qu'en redirigeant la sortie vers un fichier temporaire que j'examine, sinon l'écran devient illisible, pire que les dernières lignes que j'ai sélectionnées ici, et je suis obligé de réinitialiser le terminal pour pouvoir recommencer à travailler. Ceci me fait supposer qu'une espèce de caractère fantôme ne veut pas se laisser lire, et serait un séquence escape-bidule que je connais mal, ou l'envoie au terminal quand j'essaye de l'afficher pour voir ce qui se passe.

Code :

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

1
2
3
4
5
6
7
8
9
file1='PY/premier-526PYL-MR3.ana' -> Ok au début, puis...
fabmat:00 Les perturbations sont : 41 00 00 00 00, ltmp= 2202 22024100000000 0.00 0.00 
fabmat:00 Pert's : 41 00 00 00 00, ltmp= 2202 22024100000000 0.00 0.00, lana+imat= 1966 + 81 = 2047
fabmat:00 Les perturbations sont : 4
fabmat:00 Les perturbations sont : 4 ®
fabmat:00 Les perturbations sont : 4 ® $Î
fabmat:00 Les perturbations sont : 4 ® $Î «
fabmat:00 Les perturbations sont : 4 ® $Î « ?K
fabmat:00 Les perturbations sont : 4 ® $Î « ?K, ltmp= 2202 22024®$Ϋ?Kõ®ì\u0152?·0$=r¡¿ , lana+imat= 1966 + 82 = 2048

Code :

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

1
2
3
4
5
6
7
8
9
file1='PY/deuxième-111PYLON-MR3.ana' -> Ok au début, puis...
fabmat:00 Pert's : 81 71 00 00 00, ltmp= 2202 22028171000000 0.00 0.00, lana+imat= 1867 + 180 = 2047
fabmat:00 Les perturbations sont : 8
fabmat:00 Les perturbations sont : 8 ®
fabmat:00 Les perturbations sont : 8 ® $Î
fabmat:00 Les perturbations sont : 8 ® $Î «
fabmat:00 Les perturbations sont : 8 ® $Î « ?K
fabmat:00 Les perturbations sont : 8 ® $Î « ?K, ltmp= 2202 22028®$Ϋ?Kõ®ì\u0152?·0$=r¡¿ 
fabmat:00 Pert's : 8 ® $Î « ?K, ltmp= 2202 22028®$Ϋ?Kõ®ì\u0152?·0$=r¡¿, lana+imat= 1867 + 181 = 2048

Code :

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

1
2
3
4
5
6
7
8
9
file1='PY/troisième-211PYL-MR2.ana' -> Ok au début, puis... 
fabmat:00 Pert's : 81 00 00 00 00, ltmp= 2307 23078100000000 0.00 0.00, lana+imat= 1684 + 363 = 2047
fabmat:00 Les perturbations sont : 8
fabmat:00 Les perturbations sont : 8 ®
fabmat:00 Les perturbations sont : 8 ® $Î
fabmat:00 Les perturbations sont : 8 ® $Î «
fabmat:00 Les perturbations sont : 8 ® $Î « ?K
fabmat:00 Les perturbations sont : 8 ® $Î « ?K, ltmp= 2307 23078®$Ϋ?Kõ®ì\u0152?·0$=r¡¿ 
fabmat:00 Pert's : 8 ® $Î « ?K, ltmp= 2307 23078®$Ϋ?Kõ®ì\u0152?·0$=r¡¿, lana+imat= 1684 + 364 = 2048

On voit aussi, que bien que les fichiers soient stucturés légèrement différemment, l'erreur se produit toujours au même moment qui est la 2048-ième lecture. (avant la position de lecture, 2047 qui marche, et 2048 qui plante, j'ai fait s'afficher la taille des blocs du fichier d'entrée qui ont été lus jusqu'à présent)
Et ce nombre 2048 me fait tilt à l'instant en écrivant, serait ce une limitation informatique quelconque ou quelque chose que je n'aurai déclaré qu'à 2K ?

Est-ce que quelqu'un aurait une idée de vérification à faire ? Toutes les idées et questions sont bienvenues puisqu'elles pourraient m'amener à vérifier une chose à laquelle je n'aurais pas pensé et qui pourrait peut-être m'amener à comprendre le problème.
Merci,
David

[dva2tlse]

Je me réponds à moi mêmé puisque j'ai pas mal avancé;

j'ai vérifié que le sous programme lecana, qui lit le fichier d'entrée gigantesque que j'appelle le ".ana" fonctionnait bien, et qu'il me remplissait correctement la table de deux millions de chaines de quarante caractères, représentant chacune une ligne du ".ana";

par contre, un autre sous-programme lit un autre fichier, le ".pch", en six boucles. Et ça change l'image en mémoire du grand tableau quelque part entre le milieu de la troisième boucle et celui de la quatrième.

Pourtant ce sous-programme n'agit pas du tout sur le grand tableau de lignes, puisque j'ai même dû le rajouter en argument d'entrée quand j'ai vu que le grand tableau devenait corrompu pendant le déroulement de ce sous-programme lecpch.

Hédonc je m'apreçois que la 2048-ième ligne du tableau change pendant le déroulement de ce sous programme lecpch alors que rien ne semble le provoquer.

Si vous avez des idées, merci de me les donner pour avancer encore un peu.
David

[Sylvain Bergeron]

Ça ressemble beaucoup à un mauvais passage de paramètre. Tu appelles probablement une fonction/routine en ne passant pas le bon nombre de paramètres.

[dva2tlse]

En effet, ça ressemble un peu à un mauvais passage de paramètre. Mais j'appelle habituellement les fonctions/subroutines avec une liste d'arguments copiée et recollée pour justement éviter ce genre d'erreur plus ou moins courante. M'enfin je vais vérifier quand même s'il n'y a pas un bloc qui viendrait se superposer mal à propos.
Merci,
David

[dva2tlse]

Heu... En fait il n'y a pas d'emplacement précis du fichier d'entrée avec ce que je croyais être un "caractère fantôme" puisque à chaque fois que je change le code, pour affiner ce que je supposais être une localisation dangereuse, la ligne à partir de laquelle le programme se met à afficher des insanités change; ce qui doit bien vouloir signifier que ça dépend du remplissage de la mémoire.
Alors peut-être que Valgrind m'aiderait... ? Ou un outil un peu similaire qui me montrerait comment est utilisée la mémoire.

[Sylvain Bergeron]

Je ne suis pas un grand utilisateur de débogueur, mais j'en ai déjà utilisé un qui avait la capacité de définir des points d'arrêt à l'écriture à un adresse de mémoire. Ça permettait de trouver rapidement la source de ce genre d'erreur.

Autre piste: Essayer de décoder les insanités. J'ai souvent trouvé la cause de cette façon: Tu essaies de convertir les octets en défaut en integer, en real 4, en real 8, en déplaçant d'un octet à la fois pour faire des blocs de 4 ou 8 octets consécutifs ,... en essayant d'obtenir une valeur ayant du sens dans ton application.

[dva2tlse]

J'ai trouvé; des gens du forum d'ubuntu m'ont mis sur la piste d'une option -fsanitize=bounds, qui n'existe pas en gfortran, mais j'ai trouvé -fbounds-check, qui fait probablement le même genre de boulot, d'après son nom, et YOUPI, plein de dépassement de bornes, par en haut ou par en bas (indice 0, de début, que j'utilise parfois au lieu du 1 standard) et ça finit par marcher !
Merci à tous,
David