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