Forum Programmation.c petit probleme avec gdb et la structure pthread_mutex_t

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
25
mai
2020

Bonjour à tous,

voila je me suis fabriqué un petit programme qui fait un deadlock (via 2 threads). puis ensuite avec gdb je regarde à quelle instruction est mon programme (via backtrace), j'ai :

#0  __lll_lock_wait ()
    at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f623ede4023 in __GI___pthread_mutex_lock (
    mutex=0x5571dcb2c040 <mutexDeCosmoff>)
    at ../nptl/pthread_mutex_lock.c:78
#2  0x00005571dc92b89b in callback1 ()
#3  0x00007f623ede16db in start_thread (arg=0x7f623e9e8700)
    at pthread_create.c:463
#4  0x00007f623eb0a88f in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

je constate donc que mon thread est bloqué par le mutex : mutexDeCosmoff
je veux regarder la valeur cette structure, je regarde dans pthread.h et on a :
```
typedef struct pthread_queue {
struct pthread *head;
struct pthread *tail;
} *pthread_queue_t;

 typedef struct {
         struct pthread_queue queue;
         char lock;
         struct pthread *owner;
         int flags;
 #ifdef _POSIX_THREADS_PRIO_PROTECT
         int prioceiling;
         pthread_protocol_t protocol;
         int prev_max_ceiling_prio;
 #endif
 } pthread_mutex_t;

```pour accéder à la valeur lock de ma structure pthread_mutex_t, je lance la commande sous gdb : (gdb) print ((char*)&mutexDeCosmoff)[16]
le 16 correspond au décalage que je dois faire pour accéder à la variable lock

malheureusement gdb me retourne 0 alors que je m'attendais à 1 ou 2

avez vous une idée ?

Merci d'avance pour votre aide

  • # mutex ou sémaphore ?

    Posté par  . Évalué à 1.

    Salut,

    Moi ça ne me choque pas pour un mutex.

    Peut-être que tu aurais 1 ou 2 si c'était un sémaphore ;)

    Matricule 23415

  • # Décompte

    Posté par  . Évalué à 2.

    Quand on utilise un sémaphore, on compte le nombre de ressources disponibles. Chaque fois qu’on prend un sémaphore P(x) on décrémente x. Si celui-ci vaut 0, alors on attend qu’il soit à 1.
    Un mutex n’est finalement qu’un sémaphore avec une seule ressource. Donc sa valeur doit varier entre 0 et 1.
    0 ressource disponible lock attend.
    1 ressource disponible lock prend et change la valeur à 0.

    • [^] # Re: Décompte

      Posté par  . Évalué à 1. Dernière modification le 26 mai 2020 à 09:26.

      merci pour vos réponses.

      J'ai donc testé le code ci dessous :
      void* callback1( void* t)
      {
      for (int i = 0; i < 1; ++i)
      {

      pthread_mutex_lock ( &mutexDeCosmoff );
      printf("mutexDeCosmoff %i\n", ((char*)&mutexDeCosmoff)[16] );
      count ++;
      pthread_mutex_unlock ( &mutexDeCosmoff );
      printf("mutexDeCosmoff %i\n", ((char*)&mutexDeCosmoff)[16] );

          }
    return NULL;
}

      et j'ai en sortie
      mutexDeCosmoff 0
      mutexDeCosmoff 0

      donc la valeur de mon mutex ne change pas que je fasse lock ou unlock

      • [^] # Re: Décompte

        Posté par  . Évalué à 3.

        Je n’ai pas regardé l’implémentation de pthread, mais pourquoi ne pas utiliser : mutexDeCosmoff->lock pour avoir la valeur ? Compter les octets est un bon moyen d’avoir un soucis entre la taille des pointeurs en fonction de l’architecture, le padding, etc.

        On ne le voit pas apparaître dans ton code, mais j’imagine que tu as bien un pthread_mutex_init.

        Pour trouver l’erreur, tu peux faire du print debug, pour les cas de bug dynamique c’est parfois plus efficace, même si les printf ont une tendance à perturber le temps réél…

        Un truc du genre :

        #define LOCK(mutex) {\
printf("%s: try lock "##mutex##"\n",(char*)__func__);\
pthread_mutex_lock(&mutex);\
printf("%s:\t"##mutex##" locked\n",(char*)__func__);\
}

        Tu dupliques pour le unlock.

        Je ne me souviens plus trop pour la concaténation dans les macros (##) je ne suis pas certain de la syntaxe, mais tu vois le principe.

      • [^] # Re: Décompte

        Posté par  . Évalué à 1. Dernière modification le 26 mai 2020 à 18:29.

        Salut,

        Peut-être parce que quand tu fais un mutex tu compte pas, alors que dans un sémaphore, si ?

        Je sais pas, c'est trop vieux ;)

        Matricule 23415

      • [^] # Re: Décompte

        Posté par  . Évalué à 2.

        Hello, pour débugguer, avec gdb, tu peux utiliser call qui permet d'appeler une fonction.
        Par exemple tu stoppes, tu est locké, tu peux faire call pthread_unlock(&mutex). Ça n'aidera pas à trouver qui a locké, mais ça peut permettre d'aller plus loin, et peut-être de trouver le responsable…

        Quel type de mutex tu utilises ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.