Discussion :

[Moine]

Salut tout le monde,

pour résoudre un problème de référence croisée j'ai dû faire une pré déclaration. Quand je fait un delete de la classe pré déclarer dans le destructeur j'obtiens un segmentation fault.

Code :

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

1
2
3
4
5
6
7
8
9
 
class A;
 
class B
{
  A *t;
B(){ t = new A();}
~B(){ delete t;} //segmentation fault à l'execution 
}

même chose avec

Code :

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

1
2
 
 if(t) delete t;

Je voudrais comprendre ce qui se passe, pourquoi le delete ne fonction pas. ça me parait bizard

[Arzar]

En quoi ton code expose le problème ?

[jabbounet]

Ta description est un peu légère,

Peux tu montrer comment A et B interagissent entre elles,
As tu des relations d'héritage, d'amitié entre elles.
Quels méthode de B implique/utilise A et inversement.

[Cheps]

Est-ce que ta classe A détruit un élément de type B dans son destructeur?

[loufoque]

Le code fourni ne peut compiler.
Merci de fournir un exemple réduit qui exhibe le problème.

[Moine]

Est-ce que ta classe A détruit un élément de type B dans son destructeur?

non, nul part je ne fait ça.

J'ai exécute le code avec la partie à problème en commentaire, j'ai eu droit au segmentation fault des fois et souvent rien, je me dis donc qu'il s'agit d'un problème de fuite de mémoire.

si quelqu'un peu me dire comment pister une fuite de mémoire avec code block, avec ça j'arriverais sans doute à résoudre mon problème. merci

[jabbounet]

non, nul part je ne fait ça.

J'ai exécute le code avec la partie à problème en commentaire, j'ai eu droit au segmentation fault des fois et souvent rien, je me dis donc qu'il s'agit d'un problème de fuite de mémoire.

si quelqu'un peu me dire comment pister une fuite de mémoire avec code block, avec ça j'arriverais sans doute à résoudre mon problème. merci

fuite memoire (valgrind si tu es sous linux) ou
multithreading, si un thread s'amuse à te modifier/détruire A pendant que tu le détruit ça peux faire ce genre de chose.

[Moine]

merci pour Valgrind, je m'en vais voir à quoi il ressemble.

[Médinoc]

Je suis étonné qu'un delete sur un type incomplet compile: Le compilateur ne saurait pas où trouver le destructeur, et même s'il suppose, il ne saurait pas s'il est virtuel ou non!

[3DArchi]

Un problème de RAII ? Besoin d'un pointeur intelligent pour éviter un double delete ?

[r0d]

Je vois 2 explications possibles:
1. t n'est pas initialisé (il aura une valeur du type 0xcdcdcdcd), ce qui signifie que ton constructeur par défaut n'est pas appelé
2. t a déjà été effacé (double delete, comme dit 3DArchi), auquel cas il faut chercher ailleurs dans ton code

[r0d]

Je suis étonné qu'un delete sur un type incomplet compile: Le compilateur ne saurait pas où trouver le destructeur, et même s'il suppose, il ne saurait pas s'il est virtuel ou non!

Oui c'est vrai c'est étrange, mais ça compile (et ça merche). Je suppose que lors de la compilation de B, le compilo se contente de savoir que A existe, en laissant un pointeur vide pour le delete (et autres références à A). Et lorsque, plus tard, A et ses descendants sont compilés, il remplit ces adresses vide (¿?)

[Emmanuel Deloget]

Oui c'est vrai c'est étrange, mais ça compile (et ça merche). Je suppose que lors de la compilation de B, le compilo se contente de savoir que A existe, en laissant un pointeur vide pour le delete (et autres références à A). Et lorsque, plus tard, A et ses descendants sont compilés, il remplit ces adresses vide (¿?)

C'est plus tarabiscoté que ça. Cf mes posts Les pièges de l'opérateur delete et std::auto_ptr<> et fuite de mémoire sur mon blog.

En gros, pour résumer, si on delete un type incomplet T, la plupart des compilateurs se contente de fournir un destructeur trivial inline implicite à ce type incomplet. Bien évidemment, ce destructeur ne fait rien. l'opérateur delete libère donc seulement la mémoire utilisée par l'instance de T, mais n'appelle pas son véritable destructeur.

En ce qui concerne l'erreur de l'OP, j'aurais tendance à dire qu'une séance de debug avec un debugger correct devrait lever le problème. A moins que la mémoire ait déjà été libérée ou que t soit invalide, le code ne devrait pas planter (non, une fuite de mémoire ne provoque pas de plantage). Pour trouver la cause réelle au problème, il me semble que plus de code serait le bienvenu.