[OpenMP] Erreur de segmentation

Bonjour, j'ai à mon boulot, une machine REDHAT à 32 proc's, que je voudrais utiliser pleinement pour faire du calcul en parallèle et donc rapide.
J'utilise gfortran et OpenMP pour cela, mais j'ai une segfault incompréhensible.
Est-ce que quelqu'un pourrait m'indiquer quelle option de gdb permet de connaître le nom de la variable sur laquelle une segfault a fait planter le programme.
Je ne connais que "bt" qui me donne la ligne sur laquelle s'est arrêté le programme, mais il se trouve que c'est la ligne principale de parallélisation du programme, et que cette ligne mentionne toutes les variables, en indiquant si elles sont PRIVATE à chacun des threads parrallèles, ou au contraire si elles sont SHARED (partagées) entre tous les threads.
Je sais que valgrind pourrait servir à ça aussi, mais je ne l'ai carrément jamais utilisé.
Merci,
David

Bonjour,

Mon premier réflexe eût été de splitter la directive openmp en coupant shared et private, mais je doute fort que ça avance le schmilblick.
Pour l'utilisation de gdb, en général, en mettant le flag de debug -g à gfortran, il y a plus d'infos que le seul numéro de ligne qui puisse permettre de remonter à la source d'erreur. Le problème survenant visiblement, dans ce cas, au moment ou les threads sont appelés, ça risque d'être plus difficile que d'habitude.

Cordialement,
xflr6

Bonjour, NON en effet, splitter ne change rien puisque c'est une directive unique, même si elle s'étend sur plusieurs lignes; donc la segfault est sur la dernière ligne, sans plus de précision quant à la variable qui la cause.

Certes, je m'en doutais, mais bon ça aurait permis de mieux visualiser le pb.
Pour le backtrace, on peut connaitre le niveau dans lequel il est survenu (en regardant les fonctions qu'on a implémentées, pas les autres natives sur lesquelles on peut a priori compter).
En se placant à ce niveau puis en regardant les variables locales, on peut savoir si par exemple une "dummy" variable private n'a pas été correctement initialisée dans un thread. J'ai l'impression que ça se passe avant, mais bon.

Sur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

program test implicit none integer :: i, k double precision, dimension(4) :: f double precision :: x f(1)=1.d0 f(2)=1.d0 f(3)=1.d0 f(4)=1.d0   x=104881273576.d0*RAND(); k=int(x)   print *, x,k,f(k)   end program test

---

la backtrace donne :

Code:

---

1 2 3 4 5 6 7 8 9 10

#0 0x00007ffff7ba9ad0 in ?? () from /usr/lib/x86_64-linux-gnu/libgfortran.so.3 #1 0x00007ffff7bab7af in ?? () from /usr/lib/x86_64-linux-gnu/libgfortran.so.3 #2 0x00007ffff7bac25f in ?? () from /usr/lib/x86_64-linux-gnu/libgfortran.so.3 #3 0x0000000000400976 in test () at xxx.f90:14 #4 0x00000000004009bb in main (argc=1, argv=0x7fffffffe673) at xxx.f90:16 #5 0x00007ffff708dead in __libc_start_main (main=<optimized out>, argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe3e8) at libc-start.c:244 #6 0x0000000000400789 in _start ()

---

puis

Code:

---

1 2 3 4 5 6 7

(gdb) frame 3 (num du frame à partir duquel on est présumé coupable, à corréler au #3 du backtrace;-) #3 0x0000000000400976 in test () at xxx.f90:14 14 print *, x,k,f(k) (gdb) info local f = (1, 1, 1, 1) k = 800180 x = 800180.61505126953

---

où l'on comprend qu'un indice de 800180 peut être un peu abusé pour aller dans un vecteur de 4 éléments.

Bonne continuation,
xflr6

Bonjour,
je n'ai pas franchement cherché à comprendre l'exemple que tu m'as montré, mais le backtrace du gdb m'apprend déjà des choses : que ça se passe dans le prgm principal, à l'endroit où se trouve la directive "C$OMP PARALLEL DO", et en fait après la dernière clause qui lui est associée, quel que soit l'ordre des différentes clauses présentes.

L'erreur que j'obtiens quand je redirige la sortie de mon programme est :

Code:

---

1 2 3 4 5 6

$ gdb ./S<RUN04BAR > tmp04BAR warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000 Cannot access memory at address 0x7ffffb78f6f8 Cannot access memory at address 0x7ffffb78f6f8 $

---

Donc ça me donne comme je l'avais déjà vu une fois, les adresses de la variable ou des variables qu'il n'arrive pas à atteindre; j'aimerais bien savoir quelle est celle ci; est il possible d'avoir le mapping des variables que le programme met en mémoire, avec ces fameuses adressses ?

Que veut dire "no loadable sections found" ?
Merci de m'aider à avancer,
David

Il y a une petite différence entre les fins du programme exécuté sur ou ou deux threads.

1 thread :

Code:

---

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

p2srfd:01 Spch(DIR=1, IDpch=1, K=1, Z=1)=   Program received signal SIGSEGV, Segmentation fault.   0x0000000000405db6 in MAIN__.omp_fn.0 (.omp_data_i=) at /S/DATA/DVA/F90/BN/S.f:498   498 C$OMP+SCHEDULE(GUIDED)   (gdb) (gdb) (gdb) (gdb) #0 0x0000000000405db6 in MAIN__.omp_fn.0 (.omp_data_i=) at /S/DATA/DVA/F90/BN/S.f:498   #1 0x000000000040442d in MAIN__ () at /S/DATA/DVA/F90/BN/S.f:9   #2 0x0000000000419f6e in main ()

---

2 treads :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

p2srfd:01 Spch(DIR=1, IDpch=1, K=1, Z=1)=[New Thread 0x2aaaab76c940 (LWP 11205)]   Program received signal SIGSEGV, Segmentation fault.   [Switching to Thread 0x2aaaab76c940 (LWP 11205)]   0x0000000000405db6 in MAIN__.omp_fn.0 (.omp_data_i=) at /S/DATA/DVA/F90/BN/S.f:498   498 C$OMP+SCHEDULE(GUIDED)   (gdb) #0 0x0000000000405db6 in MAIN__.omp_fn.0 (.omp_data_i=) at /S/DATA/DVA/F90/BN/S.f:498   #1 0x000000366ec0dec5 in ?? () from /usr/lib64/libgomp.so.1   #2 0x000000366f00683d in start_thread () from /lib64/libpthread.so.0   #3 0x000000366e8d4fdd in clone () from /lib64/libc.so.6

---

Mais dans les deux cas c'est la dernière clause de la directive C$OMP PARALLEL DO qui fait planter le bouzin.
Elle est elle-même appelée soit par le main (1 thread) soit apparemment par le thread nouvellement crée. (2 threads)

Oh, do not worry any more,it is just a usual segfault with a mess within the indices of an array; and it has nothing to do with OpenMP.
Regards,
David