Pb de pointeur mal détruit

**olive_le_malin** · 09/01/2004, 10h17

Bonjour,
j'utilise dans un prog une liste chainée où chacun des maillons est alloué avec new, desalloué avec delete.
Mon probleme : si dans le thread n°1 je travaille sur un maillon, et que dans le thread n°2 je détruits ce maillon (en le mettant à NULL apres le delete), je me retrouve dans le thread n°1 avec un maillon non nul, mais détruit, et du coup je ne peux pas faire if(p != NULL)

En gros :

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
18
19
20
 
thread 1 :
csPile.Lock();
info = p->info;
csPile.Unlock();
 
thread 2 :
csPile.Lock();
delete p;
p = NULL;
csPile.Unlock();
 
thread 1 :
csPile.Lock();
if(p != NULL)  //ça passe
info = p->info;  //ça plante
csPile.Lock();
 
 
Merci par avance

**farscape** · 09/01/2004, 10h26

salut a tout reorganiser tu peux utiliser ça :

Code :

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

1
2
3
4
 
// example for AfxIsMemoryBlock
CAge* pcage = new CAge( 21 ); // CAge is derived from CObject.
ASSERT( AfxIsMemoryBlock( pcage, sizeof( CAge ) ) )

AfxIsMemoryBlock te diras si l'adresse allouer est valide.

**tut** · 09/01/2004, 10h50

slt,
t'aurais pas un problème de synchronisation ?
normalement, si tu fais un Lock() ta structure de données doit être protégée, et tu dois être sûr que tant qu'elle est lockée, personne n'y a accès, donc si tu fais un delete et p=NULL, normalement, un thread qui veut y avoir accès doit être en attente de la libération de la ressource...
Si ton mécanisme de synchronisation est bien fait, le problème ne devrait pas se poser.

**olive_le_malin** · 09/01/2004, 11h00

la liste chainee est bien protégée.
C'est simplement que dans le thread 1, je fais le unlock() pour laisser la main a un autre thread, et puis je la re-lock() pour faire du traitement dessus.
Et c'est dans ce laps de temps (entre le Unlock() et le lock()) où le 2nd thread intervient sur la liste chainée (et il en a le droit puisqu'elle n'est pas lockée), et qu'il delete le maillon. C'est ensuite que dans le thread 1 (apres le lock) ce maillon n'est pas nul, mais quand même détruit.

Alors qu'il soit détruit, c'est normal !! Mais qu'il ne soit pas nul (alors que je le met à NULL dans le thread 2), ça je comprends pas !!

**farscape** · 09/01/2004, 11h13

comme c'est pas coherent soit ton lock echoue soit c''est pas la meme variable.

**olive_le_malin** · 09/01/2004, 11h16

AfxIsMemoryBlock plante ("user breakpoint caller from code ...") !!!

**olive_le_malin** · 09/01/2004, 11h23

je t'assure qu'il n'y a pas de pb de lock() / Unlock().
Quand à la variable c'est la même, puisqu'en travaillant au debugger, je vois trés bien que l'adresse du maillon p est bien la même dans le thread 1 et dans le thread 2.

Je ne comprends donc pas

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
18
thread 1 : 
csPile.Lock(); 
info = p->info; //OK
csPile.Unlock(); 
 
Sleep(10000); //C'est pendant ce temps que le thread2 accede à la liste
 
csPile.Lock(); 
if(p != NULL)  //ça passe (ça ne devrait pas !!!!!)
    info = p->info;  //ça plante 
csPile.Unlock(); 
 
 
thread 2 : 
csPile.Lock(); 
delete p; 
p = NULL; 
csPile.Unlock();

**abelman** · 09/01/2004, 12h54

Hum,
csPile est donc un objet CCritcalSection. (OK ?)
Quelle est sa portée ? C'est bien une variable globale ?

**olive_le_malin** · 09/01/2004, 15h09

oui

**bilb0t** · 09/01/2004, 15h47

C'est pas pasque tu détruit un object et que tu mets son pointeur à NULL que tout les pointeurs le référençant vont être à NULL !

**abelman** · 09/01/2004, 21h02

Envoyé par bilb0t

C'est pas pasque tu détruit un object et que tu mets son pointeur à NULL que tout les pointeurs le référençant vont être à NULL !

Ben si normalement. Ou alors je t'ai mal compris

**farscape** · 09/01/2004, 23h05

c'est incompréhensible ton pb il faudrait voir le code en entier
c'est pas possible ça doit etre gros comme une maison!
entre autre l'endroit ou sont declarées les variables etc...

**olive_le_malin** · 12/01/2004, 10h45

Alors pour solutionner mon probleme, je suis passé par un pointeur de pointeur.
Je crois que ça rejoint ce que disait bilbOt.

J'ai fait (sachant que *pp du thread1 <-> p du thread 2)

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
18
19
20
 
thread 1 : 
pile** pp = NULL;
csPile.Lock(); 
info = (*pp)->info; //OK 
csPile.Unlock(); 
 
Sleep(10000); //C'est pendant ce temps que le thread2 accede à la liste 
 
csPile.Lock(); 
if(*pp != NULL)  //et là c'est bon
    info = (*pp)->info;
csPile.Unlock(); 
 
 
thread 2 : 
csPile.Lock(); 
delete p; 
p = NULL; 
csPile.Unlock();

Vous voyez une incorrection ou qqch d'incohérent ?

mat.M · 12/01/2004, 11h08

Bonjour,
pourquoi utiliser Sleep ??? Il ne faut pas utiliser Sleep , j'ai fait la même remarque sur le forum C++ Builder .
Comme l'a suggéré mes prédecesseurs , c'est ( on s'en doute ) , un problème de synchronisation.
Mais par pitié ne pas utiliser Sleep c'est ça qui occasionne des blocages.
Pourquoi il faut absolument éviter Sleep : pour la bonne et unique raison que tu espères attendre mettons 10 sec soient 10000ms.
Le problème est : quel est le temps d'exécution des processus indépendants qui sont crées ? Y-a-t-il une bonne synchronisation ?
Et comment va tourner ton programme dans 3 ans sur une machine 2 fois plus rapide ?

A chaud comme cela difficile d'apporter une solution ,il faut peut-être utiliser des Event ou autres .

mat.M · 12/01/2004, 11h11

MSDN:

You have to be careful when using Sleep and code that directly or indirectly creates windows. If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. If you have a thread that uses Sleep with infinite delay, the system will deadlock. Two examples of code that indirectly creates windows are DDE and COM CoInitialize. Therefore, if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than Sleep.

**olive_le_malin** · 12/01/2004, 16h23

Il n'y a pas de blocage !!
c'est simplement que si mon pointeur est détruit et remis à NULL dans le thread 2, il n'est pas NULL dans le thread 1.
A force d'essayer des trucs, j'en suis venu à l'utilisation d'un pointeur de pointeur passé au thread 1, et seul un pointeur de pointeur dans le thread 1 voit la mise à NULL dans le thread 2.

Mais je vous assure qu'il n'y a aucun probleme de blocage et de synchronisation.
Concernant le Sleep utilisé, il est vrai que ce n'est pas trés Catholique, mais c'est plus pour l'exemple que pour autre chose. En fait c'est pendant ces 10 secondes (j'aurais pu mettre 60 secondes ou même plus), qu'à la main (par une touche de raccourci incluse dans mon programme) je lance le thread 2 qui accede à la pile, et supprime un maillon !!

Alors, voyez-vous une autre manière de tester ce pointeur deleté et mis à NULL ?

mat.M · 12/01/2004, 16h52

Ok d'accord il n'ya pas de blocage mais qu'en est-il sur une autre machine dans un contexte d'exécution différent ?
Il faut trouver une autre méthode

**olive_le_malin** · 15/01/2004, 12h52

En gros voici quel était mon probleme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
char* p = new char[32];     //p vaut 0x00421ae0
strcpy(p, "le pointreur");     //*p = "le pointeur"
 
char* p2 = p;                    //p2 vaut 0x00421ae0, *p2 = "le pointeur"
 
delete p;                          //liberation de la memoire prise par p
                                       //avec *p = *p2 = "YYYYYYYYYYYYYYYY"
p = NULL;                         //p vaut 0x00000000
 
//MAIS p2 vaut toujours 0x00421ae0

La seule maniere de voir au travers de p2 que p vaut NULL est de faire

Code :

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

1
2
3
4
5
6
7
8
9
 
char* p = new char[32];     //p vaut 0x00421ae0
strcpy(p, "le pointreur");     //*p = "le pointeur"
 
char** p2 = &p;                //*p2 = p = 0x00421ae0, **p2 = "le pointeur"
 
delete p;                          //liberation de la memoire prise par p
                                       //avec *p = **p2 = "YYYYYYYYYYYYYYYY"
p = NULL;                         //p = *p2 = 0x00000000

Donc je me suis bien fait avoir en pensant que lorsque l'on détruit un pointeur et qu'on le met à NULL, on va aussi mettre à NULL tous les pointeurs le référençant (ce qui soulignait bilbOt, donc attention abelman !)

**abelman** · 15/01/2004, 13h17

Ok Je vais tester cela

**farscape** · 15/01/2004, 13h44

Moi ça me semble tout a fait normal c'est le piége typique que l'on retrouve
dans une classe avec des données membres de type pointeur quand on a pas fait un constructeur de copie et d'affectation lorsque l'un des 2 mécanismes est évoqué on a 2 objets avec des pointeurs qui adressent la même mémoire
Lorsque l'un des 2 objets se détruit et fait son ménage l'autre objet a des pointeurs qui adressent du vent
C’est bien pour ça qu'au début je t'ai demande si on parlait de la même variable p dans 2 thread apparemment non.
Et pas un autre variable nommée p .

Pb de pointeur mal détruit

MFC

Vue hybride

Discussions similaires

Partager

Partager