[contourné] parallélisation avec openmp, et gdb

dva2tlse · Le 31/10/2013, à 20:34

Bonjour tous les gens du forum,
à mon boulot, j'ai à faire un assez gros programme en fortran, gros pour moi qui ne suis pas informaticien mais ingénieur mécanicien, et ce programme doit tourner assez vite pour être utile. Une certaine tâche de base (très complexe cependant) met quelques secondes à tourner, et il faudrait en faire environ trois cent mille dans la semaine, ce qui laisse environ deux secondes par tâche unitaire.
J'en ai déjà parlé plusieurs fois sur ce forum, et l'on m'a bien aidé; ce qui se passe désormais, est que j'ai décidé de paralléliser l'affaire avec openmp, puisqu'il y a dans ma boite plusieurs machines multiprocesseur, et qu'il me semble être arrivé à peu près "au bout" des optimisations sur un seul proc'; je vois donc ainsi, en parallélisant, une issue possible satisfaisante.
Cependant, pour l'instant je bute sur une particularité du calcul parallèle : après avoir commencé séquentiellement, le calcul devient parallèle, et il faut choisir soigneusement parmi les données, celles qui vont être propres à chaque branche du calcul (PRIVATE), et celles qui vont être partagées entre toutes les branches. (SHARED)
Et c'est à ce moment là que mon programme plante, et je n'arrive pas à en connaître la raison.
J'ai essayé de compiler (j'utilise gfortran) avec l'option "-g" pour pouvoir utiliser le debugger gdb, et voici ce qu'il me raconte après un démarrage ordinaire :

Cannot access memory at address 0x7ffffd8a2618
0x0000000000407c61 in MAIN__.omp_fn.0 (.omp_data_i=) at /L/DATA_PROJECTS9/DAVID/F90/BN/rfomp1.f:1183
warning: Source file is more recent than executable. [ce qui n'est pas vrai, mais il le dit toujours]
1183 C$OMP+SHARED(Ccvt1, Ccvt2, elem, elemout, FSCVT2, lina) [ça c'est l'instruction qui plante, et sa ligne]
Cannot access memory at address 0x7ffffd8a2618

Je ne connais pas gdb (sauf "bt"), alors j'ai essayé de demander "info symbol 0x7ffffd8a2618", en espérant avoir le nom de la variable boiteuse, mais il répond "No symbol matches 0x7ffffd8a2618.".
Dans gdb, "info variables" me donne une longue liste d'adresses avec les variables correspondantes, mais pas la bonne adresse, et donc je ne sais pas quelle variable pose problème, ce qui pourrait pourtant m'aider grandement.
Les divers tutos et user guides que j'ai pu consulter, m'indiquent comment faire du pas à pas, mettre des points d'arrêt et lire les valeurs des variables, mais pas ce que je veux.

Comment puis-je savoir quel est le nom de la variable qu'il n'arrive pas à atteindre ?

Merci de m'aider autant que possible,
David

Dernière modification par dva2tlse (Le 02/11/2013, à 10:53)

omc · Le 01/11/2013, à 09:49

Bonjour,
Tu peux demander un "backtrace" pour remonter la pile des appels. Ensuite tu peux faire des "up" et "down" jusqu'à obtenir la raison du sigsev.
gdb n'est pas très sympathique à utiliser, tu peux aussi te tourner vers des front-end comme ddd.
Bon dev !

dva2tlse · Le 01/11/2013, à 11:56

Bonjour omc-lève-tôt,
"remonter la pile des appels" j'entrevois un peu ce que ça signifie, et d'ailleurs ça me semble être ce dont gdb me donne la fin à la gamelle; je viens de réussir à reproduire chez moi la gamelle avec SISGEV, mais avec des subroutines vides qui ne font aucun travail, juste les définitions de variables qui me semblaient poser problème et le return :

david@test:~/G/RAINFLOW$ gdb ./rfomp1<RUN
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/david/G/RAINFLOW/rfomp1...done.
(gdb) Starting program: /home/david/G/RAINFLOW/rfomp1
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
rfomp1 () at rfomp1.f:161
161 program rfomp1
(gdb) #0 rfomp1 () at rfomp1.f:161
#1 0x0804ab5b in main ()
#2 0x00278bd6 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#3 0x08048b01 in _start ()
(gdb) A debugging session is active.

Inferior 1 [process 28712] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

Mais il semble se planter dès le début, alors qu'au boulot ça avance jusqu'à beaucoup plus loin, là où se produit effectivement le partage des variables entre PRIVATE et SHARED.
Alors je ne sais pas si je pourrai faire quelque chose d'utile avec ma machine à simple proc' et mes routines vides, mais peux tu m'expliquer ce que tu veux dire par "faire des "up" et "down" jusqu'à obtenir la raison du sigsev" ?
Ça, faire des up et down je l'ai fait tout à l'heure mais je ne sais pas bien interpréter ce que ça me répond, et "obtenir la raison du SISGEV", je voudrais des explications parce que je ne comprends même pas la phrase, juste les mots.
À bientôt peut-être,
David

EDIT: PS. Quant à utiliser autre chose que gdb, je suis un peu "en froid" avec l'admin' qui n'a pas apprécié que je lui pirate les mots de passe windows et unix et linux, qui se trouvent être les même sur toutes les machines, donc je ne peux plus lui demander d'installer quoi que ce soit, dont je serais le seul utilisateur de surcroit. J'avais pourtant lu dans un de mes propres fils, l'existence d'un debugger pour les applications parallèles, mais on verra ça dans une autre vie si je fais encore du code...
D.

Dernière modification par dva2tlse (Le 01/11/2013, à 12:05)

dva2tlse · Le 02/11/2013, à 10:52

Ça y est youpi ça marche; le souci que j'avais jeudi et avant sur le multi-threading est résolu; jeudi j'avais demandé de l'aide à deux américains qui bossent sur un forum d'aide aux personnes qui utilisent comme moi l'API (Application Program Interface) openMP pour les tâches en Multi Processeur, et ces gens là m'ont demandé de leur poster mon programme principal qui déconnait, ainsi que les déclarations de variables qui sont faites dans tous les sous programmes pour examiner le tout.
Et vendredi matin j'ai voulu de mon côté continuer d'examiner le problème, donc je suis allé sur leur site et j'ai recopié ce que j'avais posté la veille jeudi, pour le faire tourner chez moi sur ma machine; je n'avais que des subroutines complètement bidon, qui ne faisaient aucun travail avec juste un RETURN après les déclarations, mais comme c'est justement les correspondances entre les déclarations et les arguments des subroutines et ceux utilisés lors des appels que je mettais en cause, eh bien ça m'a permis de m'apercevoir que dans un sous-programme valint qui nettoie une colonne de l'historique de ses valeurs intermédiaires, eh bien ce sous-programme s'attendait à recevoir un argument valinter déclaré comme valinter(31640, 326), soit une matrice, alors que le programme principal rfomp1 ne lui passait qu'un valinter déclaré comme valinter(31640), soit une colonne, ce qui est logique, mais ça ne correspondait pas.
Je ne sais pas depuis quand je traine cette erreur, mais il est possible que ce soit depuis cet été, juste avant ou juste après les congés; enfin bref, lundi ça devrait marcher pour ça, et il ne restera "plus" qu'à s'occuper proprement de deux autres moyennes difficultés héhop.
David

omc · Le 04/11/2013, à 12:57

Bon dev !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 31/10/2013, à 20:34

[contourné] parallélisation avec openmp, et gdb

#2 Le 01/11/2013, à 09:49

Re : [contourné] parallélisation avec openmp, et gdb

#3 Le 01/11/2013, à 11:56

Re : [contourné] parallélisation avec openmp, et gdb

#4 Le 02/11/2013, à 10:52

Re : [contourné] parallélisation avec openmp, et gdb

#5 Le 04/11/2013, à 12:57

Re : [contourné] parallélisation avec openmp, et gdb

Pied de page des forums