Discussion :

[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

[nikko34]

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

[vdaanen]

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 :

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

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

[poukill]

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

Quand tu dis :

Code :

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

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à :

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 !

[vdaanen]

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

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

Quand tu dis :

Code :

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

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

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

[Goten]

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

Une raison de pas utilisé shared_ptr?

[vdaanen]

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

[Goten]

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

[nikko34]

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...

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?

[3DArchi]

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 :

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

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.

[vdaanen]

ce qu'il faut pas entendre...

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 ...

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 ....

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

[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

[poukill]

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...

[camboui]

Code :

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

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>).

[JolyLoic]

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