Discussion :

[fred94190]

Bonjour,

J'ai rencontré cette fameuse erreur en manipulant un vecteur dans mon code... et là chose étonnante c'est que je n'ai pas manipulé explicitement la mémoire avec un free ou avec un destructeur etc... d'une manière incorrecte, et pourtant ce sont les principales causes pour cette erreur si j'ai bien suivi.

Voici mon code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
vector<CDart> fonction(CDart* d){
    vector<CDart> vect;   
    CDart* dartCourante = d;
    vect.push_back(*dartCourante);
   do{
        vect.push_back(*dartCourante);
        dartCourante = dartCourante->next();
    }while(isEqual(dartCourante->next(), d->next() == false); 
 
    vect.push_back(*d);
 
    return vect;
}

L'objectif ici est de stocker tous les objets de type CDart dans un vecteur en utilisant la fonction next de la classe CDart. (Dans la pratique ces objets sont liés entre eux par une liste chainée). A la fin je réajoute l'élément de début (ça m'est utile par la suite, car j'y ajouterai plusieurs listes chainées consécutives et la répétition de cet élément me servira de point de repère dans mon vecteur).

Après des tests pour voir ce qui pose problème, je m'aperçois que c'est l'ultime ajout dans le vecteur qui est en défaut... mais pas systématiquement.

Je ne vois vraiment pas en quoi j'ai tripatouillé la mémoire de manière incorrecte... quelqu'un peut m'aider ?

Merci d'avance !

[Neckara]

Bonjour,

Ne serait-ce pas un problème au niveau de l'opérateur d'affectation de CDart ?

J'ai l'impression que tu place deux fois le premier élément dans ton std::vector.

Peux-tu nous montrer comment est construite cette classe ?

[fred94190]

Bonjour,
Oui je place effectivement mon élément 2 fois dedans.
Si on raisonne par exemple sur les entiers de 1 à 5 (plutot que des CDarts), je vais avoir quelque chose comme ceci :
fonction(1) = <1, 2, 3, 4, 5, 1>
L'objet passé en paramètre à ma fonction va engendrer une série qui finit obligatoirement par boucler. Je m'arête quand j'ai repéré cette boucle, et je rajoute une dernière fois le dernier élément à la fin. Pourquoi ? parce que par la suite je vais "coller" à la fin de ce vecteur le résultat de la fonction appliqué à un autre élément et ile me servira (entre autre) de séparateur entre ces chaînes.
Au final j'aurais par exemple : <1, 2, 3, 4, 5, 1, 6, 7, 8, 6, 9, 10, 11, 9...>
ce qui signifierai que j'ai une boucle ici qui va de 1 à 5, une autre de 6 à 8, une autre de 9 à 11 etc.
Ce formatage des données n'est pas de mon fait, mais il a sa raison d'être et je ne peux pas le modifier (sauf si VRAIMENT c'est capital).

Je ne peux pas linker le code de la classe CDart ici (il est réellement ENORME),
Mais en résumé il s'agit d'un objet qui modélise une sorte d'arête orientée faisant parties de chaines, avec des fonctions qui pointent vers son successeurs, son antécédent, et d'autres CDarts bien particulières.

Je me posais la question : peut être ai-je mal manipulé mes pointeurs ? (mais bon je ne vois pas où !).

[Neckara]

Peux-tu au moins poster l'opérateur d'affectation de CDart ?

Il y a fort à parier que le problème de double free vienne de là (ou de l'opérateur d'affectation des attribut de CDart).

Sinon, as-tu essayé d'utiliser un débogueur pour voir précisément à quelle ligne le problème de double free survenait ?

[fred94190]

J''ai localisé l'erreur en faisant des affichages systématiques dans ma console pour savoir un peu ce qu'il se passe.

Tout ce qui se trouve avant le code suivant s'execute parfaitement

Code :

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

vect.push_back(*d);

En revanche il plante systématiquement à ce moment là. Je n'ai eu aucun warning ni aucune erreur à la compilation m'avertissant que je faisais quelque chose de risqué.

Voici les parties "clef" de la classe CDart.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
//L'attribut qui donne les liens entre les CDart (en fait un tableau de pointeurs vers des CDarts)
Private:
CDart* FBeta[3];
 
public:
//Getter et setter d'un des "liens" (le 'next' de de mon premier post)
CDart* CDart::getBeta1() const
{ return FBeta[1]; }
 
void CDart::setBeta1(CDart* ADart)
{ FBeta[1] = ADart; }

Ce code n'est pas de moi, et a priori il fonctionne dans l'appliation de base que je cherche à étendre. Je n'ai pas le droit de le modifier (d'autant qu'il impacte sur d'autres modules auquels je n'ai pas accès).

Ci-dessous le code que j'ai simplifié plus haut, mais en version "non épurée" si je puis dire, afin d'éviter les erreurs de simplification de ma part et de mieux coller aux définitions/implémentations données dans ce message :

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
21
22
23
24
 
vector<CDart> engendrerBiface(CDart* d){
    vector<CDart> biface;   
    CDart* dartCourante = d;
    biface.push_back(*dartCourante); //Ajout du premier élément
 
    //Première série de CDart correspondant à une involution
    do{
        biface.push_back(*dartCourante);
        dartCourante = dartCourante->getBeta1();
    }while(isEqual(dartCourante->getBeta1(), d->getBeta1()) == false); 
 
    //Répétition de la dart engendrant la biface (repère et séparateur entre les 2 faces la composant)
    biface.push_back(*d);
    dartCourante = d->getBeta2(); //On change de lien entre les CDarts juste pour cette fois afin d'accéder a une autre "chaine"
 
    //Deuxième série de CDart (méthode identique à la première)
    do{
        biface.push_back(*dartCourante);
        dartCourante = dartCourante->getBeta1();
    }while(isEqual(dartCourante->getBeta1(), d->getBeta2()) == false); 
 
    return biface;
}

[Neckara]

Un débogueur te donnera l'endroit exact du problème, ainsi il sera plus facile à identifier, sans compter qu'on pourra voir la valeur de certains variable et/ou exécuter pas à pas pour mieux comprendre ce qu'il se passe.

Là, on sait juste que l'erreur survient lors de l'ajout d'un élément dans le std::vector mais on ne sait pas si le problème vient d'un constructeur par copie (si oui, le quel ? Celui de l'objet, celui d'un attribut de l'objet, d'un attribut d'un attribut de l'objet ) ou s'il vient de std::vector qui aurait été mis dans un état incohérent par on-ne-sait-quelle-action.

Cela peut aussi être une erreur dans le constructeur de CDart, bref, il faudrait plus de détail sur la localisation de l'erreur.

[fred94190]

L'execution en mode debuggage comme une application native sous KDevelopp donne le résultat suivant (extrèmement long, désolé !)

Je ne relève pas de détails pour indiquer "clairement" la provenance de l'erreur. je suis prenneur de toute explication ou intuition de ce qui pourrait potentiellement créer ce problème, ou évnetuellement sur toute idée pour contourner le problème.

Merci encore,

*** glibc detected *** /nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D: double free or corruption (fasttop): 0x00000000009891b0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7ae56)[0x7ffff5f2ae56]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7ffff5f2f13c]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_ZN5Map2d5CDartD1Ev+0x3e)[0x46d426]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_ZSt8_DestroyIN5Map2d5CDartEEvPT_+0x18)[0x46ae36]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_ZNSt12_Destroy_auxILb0EE9__destroyIPN5Map2d5CDartEEEvT_S5_+0x26)[0x46a3c0]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_ZSt8_DestroyIPN5Map2d5CDartEEvT_S3_+0x23)[0x4694db]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_ZSt8_DestroyIPN5Map2d5CDartES1_EvT_S3_RSaIT0_E+0x27)[0x467825]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_ZNSt6vectorIN5Map2d5CDartESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_+0x2c4)[0x4691dc]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_ZNSt6vectorIN5Map2d5CDartESaIS1_EE9push_backERKS1_+0x78)[0x46753e]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_Z15engendrerBifacePN5Map2d5CDartE+0x15e)[0x465276]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_Z18findFrequentBifacedN5Map2d15CTopologicalMapE+0x13f)[0x464c21]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_ZN12GraphGrammarC1ESsN5Map2d15CTopologicalMapE+0x1b7)[0x4639b7]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_ZN11CMainWindow15generateGrammarEv+0x156)[0x450ec8]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(_ZN11CMainWindow11qt_metacallEN11QMetaObject4CallEiPPv+0x32d)[0x46be19]
/usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN11QMetaObject8activateEP7QObjectPKS_iPPv+0x2da)[0x7ffff6ddaeba]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN7QAction9triggeredEb+0x32)[0x7ffff72f1bb2]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN7QAction8activateENS_11ActionEventE+0x6f)[0x7ffff72f1d9f]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x6306c9)[0x7ffff772c6c9]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x636312)[0x7ffff7732312]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN7QWidget5eventEP6QEvent+0x66a)[0x7ffff7348cea]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN5QMenu5eventEP6QEvent+0x5b)[0x7ffff77338bb]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0xb4)[0x7ffff72f8474]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN12QApplication6notifyEP7QObjectP6QEvent+0xafb)[0x7ffff72fdcbb]
/usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8c)[0x7ffff6dc7afc]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb+0x172)[0x7ffff72f9442]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x27d091)[0x7ffff7379091]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(_ZN12QApplication15x11ProcessEventEP7_XEvent+0xdde)[0x7ffff737794e]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x2a44a2)[0x7ffff73a04a2]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x1dd)[0x7ffff5592a5d]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x45258)[0x7ffff5593258]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x69)[0x7ffff5593429]
/usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x76)[0x7ffff6df2ed6]
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x2a410e)[0x7ffff73a010e]
/usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE+0x32)[0x7ffff6dc6cf2]
/usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0xa7)[0x7ffff6dc6ef7]
/usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN16QCoreApplication4execEv+0x89)[0x7ffff6dcb789]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D(main+0x23c)[0x441431]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7ffff5ed130d]
/nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D[0x441099]
======= Memory map: ========
00400000-004d5000 r-xp 00000000 00:17 1827735 /nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D
006d4000-006d5000 r--p 000d4000 00:17 1827735 /nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D
006d5000-006d6000 rw-p 000d5000 00:17 1827735 /nhome/file-srv/NAME/Documents/carteTopo2D/build/ihmQT/qTopoMap2D
006d6000-00e54000 rw-p 00000000 00:00 0 [heap]
7fffd0000000-7fffd002c000 rw-p 00000000 00:00 0
7fffd002c000-7fffd4000000 ---p 00000000 00:00 0
7fffd52d9000-7fffd52da000 ---p 00000000 00:00 0
7fffd52da000-7fffd5ada000 rw-p 00000000 00:00 0
7fffd62db000-7fffd62dc000 ---p 00000000 00:00 0
7fffd62dc000-7fffd6adc000 rw-p 00000000 00:00 0
7fffd6adc000-7fffdc69f000 r--p 00000000 08:01 3274107 /usr/share/icons/hicolor/icon-theme.cache
7fffdc69f000-7fffe0000000 r--p 00000000 08:01 3550910 /usr/share/icons/gnome/icon-theme.cache
7fffe0000000-7fffe003c000 rw-p 00000000 00:00 0


[CENTAINES DE LIGNES DE MEMOIRE]

7ffff7ff9000-7ffff7ffb000 rw-p 00000000 00:00 0
7ffff7ffb000-7ffff7ffc000 r-xp 00000000 00:00 0 [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00020000 08:01 3009174 /lib/x86_64-linux-gnu/ld-2.13.so
7ffff7ffd000-7ffff7fff000 rw-p 00021000 08:01 3009174 /lib/x86_64-linux-gnu/ld-2.13.so
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
*** Program received signal SIGABRT (Aborted) ***

[Neckara]

Es-tu bien sûr de compiler et d'exécuter en mode débogue ?

Normalement donc debogueur devrait t'ouvrir le fichier où l'erreur survient et te mettre un petit "pointeur" vers la ligne de l'erreur et te donner en même temps la pile d'appel.

[fred94190]

J'avoue mal maîtriser KDevelop, j'ai "bêtement" cliqué dans l'interface à l'endroit dans l'arborescence du projet où se situait la partie executable, fait clic droit --> Debug As... Native application (seul choix possible). le résultat que j'ai copié-collé ici se situait bien dans la console de debuggage de KDevelop

En temps normal je n'utiliser même pas l'interface pour compiler mais un CMake (fourni avec le projet), donc j'avoue être un peu perdu avec les autres fonctionnalités de Kdevelop. Evidemment on m'impose de l'utiliser, je ne peux donc pas utiliser d'autres IDE comme je l'aurais souhaité.

Tu disais que c'était probablement dû comme erreur à un attribut (ou groupe d'attribut) qui aurait été mis dans un état incohérent.

Initialement tout ce qui concerne les CDarts dans le code marche bien (l'application n'a jamais eu de soucis), quand au vecteur de CDart il est déclaré et utilisé pour la première fois dans le code que j'ai joint.

Je me demande donc comment QuelqueChoseQuiFonctionne + QuelqueChoseDeFacilementObservable (la portion de code donnée) peut me mettre dans un tel cas. Je me suis relu attentivement plusieurs fois pour voir si je n'avais pas a un moment donné utilisé un pointeur sur un pointeur à la place d'un simple pointeur ou ce genre d'erreur, mais pour l'instant je n'ai rien trouvé de tel.

[therwald]

Pour coller sans risque un CDart dans ton vector, il faut qu'il se comporte comme un objet valeur (non comme un objet entité), c'est à dire qu'il fasse une deep-copie en cas d'affectation. Sinon, comme vector s'autorise parfois à faire des copies et effectue un delete sur l'original, tu te retrouve avec un double-free potentiel dès que tu l'utilises dans un vector. D'où l'insistence de Neckara pour voir le code du constructeur de copie

[fred94190]

Therwald, si j'ai bien compris, UNE solution possible dans ce cas serait d'utiliser autre chose qu'un vecteur poru stocker mes données.

J'imagine que je peux stocker tout ça dans un tableau dynamique par exemple, mais je ne risque pas de me retrouver avec le même problème ? Je préfèrerai éviter de modifier mon code intégralement (ça aura des répercussions dans pas mal d'autres fonctions) si je retourne à la case départ. Quelle structure de donnée utiliser pour éviter qu'il y ait des copies/delete non volontaires de ma part ?

En tout cas, merci des explications, j'ignorais jusque là la différence entre les objets entités et les objets valeurs.

[Neckara]

Et si tu stockais des pointeurs au lieu de stocker des copies ?

[Bousk]

Bonsoir,

je ne vois aucune raison valable de vouloir faire un vector de copie puisque tu as des pointeurs...
Ton vector est retourné par copie, et qui dit copie dit que l'original est supprimé
Le nombre de copies réalisées dans ce code est assez grandiose, et de toute évidence tes CDart ne sont pas prévus pour être copiés

[therwald]

Comme le dit Neckara tu devrais plutôt envisager un vecteur de pointeurs. Ainsi que l'a fait remarquer Bousk, tu manipules à la base des pointerus, autant rester homogène.