std::vector empty et myfirst != 0 -> crash

Bonjour,

y a t il un moyen de forcer le membre interne _myfirst d'un std::vector a etre = 0 qd le vecteur est vide ?

J'ai un cas ou le vecteur est vide et myfirst != 0 et a l'appel du destructeur du vector, ca crashe l'appli.

Avec un std::list, je n'ai pas ce pb !

V

est-ce que tu pourrais poster une exemple minimal de l'utilisation de ton vector?

ca va etre difficile :(

Le contexte est le chargement d'image a partir de plugin.
dynamiquement, ca se passe comme ca :
- le reader charge les images. ce mecanisme utilise des plugins dans des DLLs
- une fois les images chargées, le reader les copie avec d'avoir les images dans l'espace memoire de l'appli. Durant cette copie, on demande au plugin de liberer la memoire allouée a chaque image une fois cette derniere copiée.
- le reader communique par un vector<SmartPtr<Image> >

dans la methode Read, j'ai donc quelque chose comme ca

Code:

---

1 2 3 4

std::vector<std::string> files std::vector<smartptr<Image> > l_pImgs; Plugin->Read(l_pImgs, files); // les images sont dans l'espace memoire du plgin CopyImage(l_pImgs); // copies les images dans l'espace memoire appli --> l_pImgs est vide

---

lorsque le destructeur est appelé pour l_pImgs, j'ai un crash car bien que le vector ait une taille nulle, myfirst != 0 et du coup, dans le code, ca appelle une méthode deallocate... a la fin de ce process, j'ai une corruption de HEAP alors que toute la memoire a deja ete desallouée.

avec std::list, je n'ai pas ce pb !

V

C'est quoi ton smartptr? un shared_ptr? un auto_ptr?

Quand tu dis :

Code:

---

std::vector<smartptr<Image> > l_pImgs;

---

Ca veut dire que vector prend une responsabilité partagée sur les objets. C'est ça que tu veux? Parce que là :

Citation:

---

Durant cette copie, on demande au plugin de liberer la memoire allouée a chaque image une fois cette derniere copiée.

---

j'ai l'impression que la libération se fait à l'extérieure ! :?

Citation:

---

Envoyé par poukill

C'est quoi ton smartptr? un shared_ptr? un auto_ptr?

---

c'est une classe CSmartPtr, fait maison. idnetique a shared_ptr en fonctionnalité

Citation:

---

Envoyé par poukill

Quand tu dis :

Code:

---

std::vector<smartptr<Image> > l_pImgs;

---

Ca veut dire que vector prend une responsabilité partagée sur les objets. C'est ça que tu veux?

---

non, ca veut dire que les images qui arrive dans l'appli via l'appel a cette methode pourront etre partagées

Citation:

---

Envoyé par poukill

Parce que là :

j'ai l'impression que la libération se fait à l'extérieure ! :?

---

en fait, la liberation se fait dans le plugin, pas dans l'appli

Citation:

---

c'est une classe CSmartPtr, fait maison. idnetique a shared_ptr en fonctionnalité

---

Une raison de pas utilisé shared_ptr?

Citation:

---

Envoyé par Goten

Une raison de pas utilisé shared_ptr?

---

juste une raison historique... Qd on a decide de passer aux smart_ptr, on utilisait encore VC6 et on arrivait pas a compiler boost donc on a opté pour notre propre SmartPtr. Puis au fur et a mesure, cette classe s'est enrichie de macros de check notamment pour voir si on passe pas des smart ptr d'un thread a l'autre..
Il parait que les shared_ptr ne sont pas thread-safe (c'est pas moi qui le dit mais l'ing qui a developpé notre classe CSmartPtr).

voilou

V

Si les shared_ptr sont thread safe au même niveau que les built-in.

Citation:

---

Envoyé par vdaanen

Il parait que les shared_ptr ne sont pas thread-safe (c'est pas moi qui le dit mais l'ing qui a developpé notre classe CSmartPtr).

---

ce qu'il faut pas entendre...:roll:

Vous auriez peut-être dû profiter du changement de compilateur pour revenir dessus.

Bon sinon ton histoire de vector, c'est quand même pas top. Tu as essayé toi de faire un petit exemple minimum pour voir d'où viendrait le problème? Bon avec le coup du plug-in c'est pas évident. Parce que je mise plus sur vos classes maisons/votre utilisation que sur la stl... Peut être une corruption mémoire?

Citation:

---

Envoyé par vdaanen

Bonjour,

y a t il un moyen de forcer le membre interne _myfirst d'un std::vector a etre = 0 qd le vecteur est vide ?

J'ai un cas ou le vecteur est vide et myfirst != 0 et a l'appel du destructeur du vector, ca crashe l'appli.

Avec un std::list, je n'ai pas ce pb !

V

---

Salut,

Code:

---

1 2 3 4

{ std::vector temp; std::swap(temp,ton_vecteur); }// ici ton précédent vecteur devrait être détruit.

---

Ton problème me fait penser à un débordement/écrasement.

Citation:

---

Envoyé par nikko34

ce qu'il faut pas entendre...:roll:

---

comme je ne maitrise pas les boost::shared_ptr ni nos CSmatrPtr, je n'ai jamais vraiment pu attaquer une discussion de fond avec l'intéréssé mais il n'est jamais trop tard ...

Citation:

---

Envoyé par nikko34

Vous auriez peut-être dû profiter du changement de compilateur pour revenir dessus.

---

comme on a fait le changement de compilo a l'arrache, c'etait pas le moment de vouloir tout péter ....

Citation:

---

Envoyé par nikko34

Bon sinon ton histoire de vector, c'est quand même pas top. Tu as essayé toi de faire un petit exemple minimum pour voir d'où viendrait le problème? Bon avec le coup du plug-in c'est pas évident. Parce que je mise plus sur vos classes maisons/votre utilisation que sur la stl... Peut être une corruption mémoire?

---

Pour l'instant c'est dans le prog de test unitaire que ca plante, je ne peux pas faire plus simple.

J'ai vérifié que les données sont libérées et que la taille du vector decroit jusqu'a etre = 0 mais la valeur de "_Myfirst" vaut autre chose que 0.
Et dans le code de la STL, dans une methode (je ne sais plus laquelle), il y a un test sur la valeur de _Myfirst pour voir s'il faut appeler deallocate.
Je pense que le test est foireux sauf si un vector de taille nulle
doit avoir _Myfirst=0 dans ce cas, il y a un pb chez moi ...

Au fait, ca le fait aussi avec une liste, contraitement a ce que j'avais dit....

V

peut etre probleme d'options de compilation des plugins par rapport au code appelant. c'est classique. tes structures n'ont pas les meme packing/padding ou des trucs en plus (debug/release ?) à voir.
c'est souvent incomprehensible de genre de bug et en fait c'est a cause d'une merde dans ce genre.
bon courage

Citation:

---

Envoyé par Lightness1024

peut etre probleme d'options de compilation des plugins par rapport au code appelant. c'est classique. tes structures n'ont pas les meme packing/padding ou des trucs en plus (debug/release ?) à voir.
c'est souvent incomprehensible de genre de bug et en fait c'est a cause d'une merde dans ce genre.
bon courage

---

Ca ne devrait pas poser problème dans la mesure où c'est bien fait, i.e celui qui alloue désalloue. Dans ce cas, pas de problème.
En cas de responsabilité partagée, peut être par contre...

Citation:

---

Envoyé par vdaanen

Code:

---

1 2 3 4

std::vector<std::string> files std::vector<smartptr<Image> > l_pImgs; Plugin->Read(l_pImgs, files); // les images sont dans l'espace memoire du plgin CopyImage(l_pImgs); // copies les images dans l'espace memoire appli --> l_pImgs est vide

---

lorsque le destructeur est appelé pour l_pImgs, j'ai un crash car bien que le vector ait une taille nulle, myfirst != 0 et du coup, dans le code, ca appelle une méthode deallocate...

---

Si tu sais que _Myfirst!=0 c'est que t'as debuggé. Tu peux le refaire et nous donner les valeurs (d'une exécution donnée) de _Myfirst, _Mylast et _Myend juste après le CopyImage() ?
Et au passage le sizeof(smartptr<Image>).

De plus, regarde la valeur de capacity, pas uniquement de size.