IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Fortran Discussion :

[OpenMP] Erreur de segmentation


Sujet :

Fortran

  1. #1
    Membre habitué
    Homme Profil pro
    ingénieur calcul
    Inscrit en
    Décembre 2007
    Messages
    363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : ingénieur calcul
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Décembre 2007
    Messages : 363
    Points : 180
    Points
    180
    Par défaut [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
    P.S. Dis Toto, pourquoi l'univers existe-t'il ?
    Je vais y réfléchir avec Morphée et lui dès avant 22h55, donc ici, il faut se causer avant.

  2. #2
    Membre averti
    Homme Profil pro
    [SciComp]
    Inscrit en
    Août 2013
    Messages
    134
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : [SciComp]

    Informations forums :
    Inscription : Août 2013
    Messages : 134
    Points : 323
    Points
    323
    Par défaut
    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

  3. #3
    Membre habitué
    Homme Profil pro
    ingénieur calcul
    Inscrit en
    Décembre 2007
    Messages
    363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : ingénieur calcul
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Décembre 2007
    Messages : 363
    Points : 180
    Points
    180
    Par défaut
    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.
    P.S. Dis Toto, pourquoi l'univers existe-t'il ?
    Je vais y réfléchir avec Morphée et lui dès avant 22h55, donc ici, il faut se causer avant.

  4. #4
    Membre averti
    Homme Profil pro
    [SciComp]
    Inscrit en
    Août 2013
    Messages
    134
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : [SciComp]

    Informations forums :
    Inscription : Août 2013
    Messages : 134
    Points : 323
    Points
    323
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  5. #5
    Membre habitué
    Homme Profil pro
    ingénieur calcul
    Inscrit en
    Décembre 2007
    Messages
    363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : ingénieur calcul
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Décembre 2007
    Messages : 363
    Points : 180
    Points
    180
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    P.S. Dis Toto, pourquoi l'univers existe-t'il ?
    Je vais y réfléchir avec Morphée et lui dès avant 22h55, donc ici, il faut se causer avant.

  6. #6
    Membre habitué
    Homme Profil pro
    ingénieur calcul
    Inscrit en
    Décembre 2007
    Messages
    363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : ingénieur calcul
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Décembre 2007
    Messages : 363
    Points : 180
    Points
    180
    Par défaut
    Il y a une petite différence entre les fins du programme exécuté sur ou ou deux threads.

    1 thread :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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)
    P.S. Dis Toto, pourquoi l'univers existe-t'il ?
    Je vais y réfléchir avec Morphée et lui dès avant 22h55, donc ici, il faut se causer avant.

  7. #7
    Membre habitué
    Homme Profil pro
    ingénieur calcul
    Inscrit en
    Décembre 2007
    Messages
    363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : ingénieur calcul
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Décembre 2007
    Messages : 363
    Points : 180
    Points
    180
    Par défaut
    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
    P.S. Dis Toto, pourquoi l'univers existe-t'il ?
    Je vais y réfléchir avec Morphée et lui dès avant 22h55, donc ici, il faut se causer avant.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Erreurs de segmentation !
    Par anti-conformiste dans le forum Applications et environnements graphiques
    Réponses: 16
    Dernier message: 18/10/2005, 12h11
  2. Erreur de segmentation
    Par Trunks dans le forum C
    Réponses: 3
    Dernier message: 06/10/2005, 19h28
  3. Erreur de segmentation (Inconnue)
    Par Dark-Meteor dans le forum C
    Réponses: 5
    Dernier message: 08/09/2005, 14h42
  4. [Dev-C++] Erreur de segmentation...
    Par sas dans le forum Dev-C++
    Réponses: 11
    Dernier message: 26/03/2005, 15h25
  5. erreur de segmentation
    Par transistor49 dans le forum C++
    Réponses: 10
    Dernier message: 15/03/2005, 12h18

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo