Discussion :

[mar1985]

bonjour,

bien que le pb concerne la bibliothèque de open cv mais je pense que le pb est un pb en C++. c pour cette raison que je poste dans ce coin.

j'ai une boucle dans laquelle je construit enc chaque itération un tracker comme suit:

Code :

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

1
2
3
4
5
6
7
8
while (e<0.001)
{
 
KltOpenCv tracker;
 
// des initialisaitons et traitement
 
}

mais après 9 itérations un bug se produit à la fin de la boucle.
En suivant ce bug, je trouve qu'il se bloque à l'intérieur de la classe KltOpenCv que j'ai définit dans le destructeur (que je n'ai pas appelé) et dans la commande suivante:

Code :

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

if (pyramid) cvReleaseImage(&pyramid);

alors j'ai plusieurs questions:
1. Est ce que le destructeur se rappele tout seul? si oui, alors quand?
2. la commande où le bug se produit marchait pendant 8 itérations, pourquoi à la neuvième se plante???
3. Enfin, comment résoudre ce problème?

J'attends vos réponses car c assez urgent.
Merci.

[3DArchi]

Bonjour,

1. Est ce que le destructeur se rappele tout seul? si oui, alors quand?

Quand la variable sort de sa portée, elle est détruite. En l'occurrence dans le cadre du while, tracker sort de la porté à chaque fois qu'on retourne tester la condition du while. Pour t'en convaincre, tu peux tester l'exemple simple ci-dessous :

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
#include <iostream>
 
class A
{
   public:
   A(){std::cout<<"Construction de A"<<std::endl;}
   ~A(){std::cout<<"Destruction de A"<<std::endl;}
};
 
int main()
{
   int i(10);
   while(i>0){
      A a;
      --i;
   }
  	return 0;
 
}

2. la commande où le bug se produit marchait pendant 8 itérations, pourquoi à la neuvième se plante???

Si ta commande produit un comportement indéterminée ... le bug peut n'apparaître qu'à la neuvième itération même si les huit précédentes ont eu l'air de ne présenter aucun problème. Une autre possibilité est une fuite mémoire si chaque commande fait de grosses allocations et qu'elles sont perdues.

3. Enfin, comment résoudre ce problème

Debug + trace ou plus d'information sur ce que contient ta boucle.

[mar1985]

Merci de répondre.

tu peux tester l'exemple

oui j'ai bien testé et le destructeur se rappele après la commande i++; ça veut bien dire qu'il y a eu un appel de destructeur.

Si ta commande produit un comportement indéterminée

Là je ne comprends pas qu'est ce que vous voulez dire exactement par comportement indéterminée.

Une autre possibilité est une fuite mémoire si chaque commande fait de grosses allocations et qu'elles sont perdues

vraiment je ne sais pas.

Debug + trace ou plus d'information sur ce que contient ta boucle.

Là je vous demande comment pourrai je debugger de plus? comment faire pour voir plus d'info?
Le code est très très long et contient bcp de dépendance d'autre classe donc ça ne sert à rien de le déposer.

une autre question si vous permettez: si le bug se produit à chaque fois (à chaque test que je fais) dans la mm commande, ça veut dire que le pb provient de cette commande? ou est ce peut être d'autres??

[white_tentacle]

Là je ne comprends pas qu'est ce que vous voulez dire exactement par comportement indéterminée.

En C++, un comportement indéterminé est un morceau de code qui compile, parce que syntaxiquement valide, mais dont le comportement n'est pas défini. C'est à dire que ça peut planter, mais aussi fonctionner, faire un peu n'importe quoi. Le plus souvent, ça dépendra du contexte autour du code en question.

Là je vous demande comment pourrai je debugger de plus? comment faire pour voir plus d'info?

Déjà, est-ce que tu peux poster la pile d'appels que tu as lorsque ça plante ? Un peu plus de détails sur le bug ?

Le code est très très long et contient bcp de dépendance d'autre classe donc ça ne sert à rien de le déposer.

Non, mais une fois que tu auras isolé précisément le bout de code qui plante, tu pourras poster ce bout précis pour qu'on l'analyse ensemble.

une autre question si vous permettez: si le bug se produit à chaque fois (à chaque test que je fais) dans la mm commande, ça veut dire que le pb provient de cette commande? ou est ce peut être d'autres??

Vu que tu exécutes toujours la même séquence d'instructions, ça plante toujours au même endroit. Toutefois, ce n'est pas forcément à cet endroit qu'est le problème, si tu as invoqué un comportement indéterminé un peu plus tôt dans le code, tout devient possible .