Codeguard erreur sur destructeur

Bonjour,

je passe codeguard sur mon appli et j'ai une erreur que j'ai du mal � comprendre.
Mon appli est constitu�e d'une dll et d'un exe.
Ma dll exporte la fonction suivante :

Code:

---

1 2	vector<TEventData> __stdcall mLgetFaults()

---

TEventData est une classe � moi.
La partie exe r�cup�re le vector, tout se passe bien � l�ex�cution, mais si je compile avec codeguard, il me signale une erreur sur le destructeur de TEventData (qui ne fait rien vu que cette classe ne contient que de types simples) :

Citation:

---

Bad parameter in process: MonAppli.exe(6480) - c:\program files\embarcadero\rad studio\8.0\include\dinkumware\xmemory#129
A bad object (0x34F79E0) has been passed to the function.
0x006909BC Call to delete(0x03507A80)
...................
0x0040B38B - src\GenericData\EventData.h#45
.............................

---

� cette ligne j'ai le code suivant :

Code:

---

1 2 3 4

~TEventData() { };

---

Il passe donc 2 fois dans le destructeur ce qui me parait normal en fait (une fois pour la cr�ation des TEventData dans l'exe, une fois pour la cr�ation dans la dll), mais �a ne doit pas �tre le cas puisque codeguard me sort une erreur...
J'avoue que je ne comprends pas trop...:roll:

merci d'avance pour vos suggestions d'explication :P
Pascale38

En C++Builder 2007, mon CodeGuard me fait souvent des VA � la fermeture du projet, je crois que c'est au moment du d�chargement des Packages

Cela a �t� am�lior� en XE2

Sinon attention, ne partage pas d'objet entre EXE et DLL, �vite de cr�er d'un c�t� et lib�rer de l'autre c�t� !

Tu n'�change tout de m�me pas un vector directement ?
Ta DLL ne pourra �tre utilis� qu'avec uniquement la version de ton compilateur (un vector de C++Builder6 n'aura peut-�tre pas la m�me gueule m�moire que celui de C++BuilderXE2, et je ne parle m�me pas des autres compilateurs C++)

En plus, �a ne fait pas des copies dans tous les sens �a ?
Tu devrais plut�t faire une fonction respectant les conventions WinAPI

Code:

---

BOOL __stdcall mLgetFaults(TEventData* Buf, int& BufCount);

---

Buf est allou� du c�t� appelant, il indique le nombre d'�lement possible par BufCount (en nombre d'item) ou un BufSize en octet

cela renvoi un code d'erreur pour signaler un Buf trop petit
Typiquement, si tu fournis Buf NULL, la fonction calcule BufCount, permettant d'allouer la m�moire !

ce point est document� sur MSN
voici le lien
http://support.microsoft.com/kb/172396/fr
cdlt

Salut ShaiLeTroll,

bon j'avais pas envie de m'emb�ter avec des pointeurs, je sais �a fait des copies, mais bon mon vector fait 24 max donc c'est pas �norme non plus.
Mais bon merci pour l'info, je ne savais pas que c'�tait incompatible entre version de compilo !!
Sinon j'utilise XE, alors comment savoir si c'est un probl�me codeguard ou non ?

Utiliser

Code:

---

BOOL __stdcall mLgetFaults(TEventData* Buf, int& BufCount);

---

j'avoue que je trouve �a super lourd !! Allouer un Buf sans savoir sa taille avec une valeur au hasard... beurk
Bon ceci dit j'ai test�, j'alloue mon buf � 24 dans l'appelant (vu que l� j'ai la chance de savoir que c'est le max), je fais le delete dans l'appelant et j'obtiens exactement la m�me erreur codeguard... sur le delete et sur le destructeur de TEventData... :cry:

Donc DjmSoftware, merci pour ton lien, mais il semblerait qu'il n'y ait aucun rapport avec le fait que j'utilise un conteneur de la STL.

Pascale38

Citation:

---

Envoy� par Pascale38

j'avoue que je trouve �a super lourd !! Allouer un Buf sans savoir sa taille avec une valeur au hasard... beurk

---

C'est pas faux, d'o� DEUX Appels comme je l'avais expliqu� dans ma r�ponse !
Un Appel mLgetFaults(NULL, var);il rempli var avec ce qu'il faut allouer puis mLgetFaults(buf, var);Typique des API Windows !

Tu peux aussi faire une liste chain�e avec une fonction mLgetFaultsFirst(Buf) et mLgetFaultsNext(CurBuf, NextBuf)Fonctionnement du TreeView je crois !

Je pr�f�re utiliser des interfaces, ainsi, la m�moire est allou� c�t� DLL, tu peux avoir une propri�t�s Count\Items, facile � utiliser, puis une m�thode pour nettoyer !
Ainsi ma DLL n'a que deux trois Exports, dont l'un est une Factory, ensuite tout le reste c'est POO � fond !

J'utilise aussi bien des Interface C++ (class abstraitre pure) que des DelphiInterface (TInterfacedObject, GUID et Supports ...)

Not possible pour 2 appels :
En fait le "tableau" est construit dynamiquement � chaque appel, entre 2 appels il peut tr�s bien contenir +ou- d'�l�ments...

Les autres solutions, surement tr�s bien, toujours un peu lourdes � mon go�t...
Tout �a pour �changer un tableau... ;)

Ceci dit mon probl�me de base avec codeguard reste le m�me :
c'est donc codeguard qui bug ???

merci en tout cas pour toutes tes pistes !!!
Pascale38

Ce n'est pas vraiment CodeGuard qui bug mais qui ne comprend pas que l'on lib�re un objet allou� dans l'espace m�moire d'un processus A dans un module B
Cela vient plutot de Windows et la gestion m�moire entre EXE et DLL

C'est pour cela qu'il existait ShareMem en Delphi
La RTL dynamique doit �tre aussi un aspect de cela !

Tant que ta DLL reste une utilisation interne et non utilisable par des logiciels tiers, tu peux te permettre ta m�thode

Je te conseille de suivre la m�thode de l'article de DjmSoftware !
Un petit pointeur �a ne fait pas de mal !

ton code actuel

Code:

---

vector<TEventData> __stdcall mLgetFaults();

---

remplace le par

Code:

---

1 2 3 4 5 6

typedef vector<TEventData> TEventDataVector; typedef TEventDataVector* PEventDataVector;   PEventDataVector __stdcall mLgetFaults(); void__stdcall mLFreeFaults(PEventDataVector Vector);

---

Ainsi, tu �changes un pointeur cr�� par la DLL
Il faudra juste lib�r� manuellement !
CodeGuard sera content de voir que Allocation et Lib�ration sont effectu� du m�me c�t� !

Je ne fais du C++ que depuis un an, en Delphi les habitudes ne sont pas les m�mes mais pour ton cas un code fa�on RAII serait id�al

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

struct TEventDataReader { PEventDataVector Items;   TEventDataReader() { Items = mLgetFaults(); }   ~TEventDataReader() { mLFreeFaults(Items); } }

---

Dans ton juste en d�clarant un TEventDataReader cela app�le la DLL, et en le lib�re implicitement


Tu peux aussi diff�r� la lecture, si tu ne veux pas que d�s que l'instanciation se produit cela appelle la DLL, par exemple si tu veux en faire un membre de classe

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

struct TEventDataReader { PEventDataVector Items;   TEventDataReader() : Items(NULL) {};   int ReadItems(); { Items = mLgetFaults(); return Items->size(): }   ~TEventDataReader() { if (Items) mLFreeFaults(Items); } }

---

le code d'appel �tant tr�s simple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

void MaFonction() { ...   TEventDataReader Reader; if (Reader.ReadItems() > 0) { for (TEventDataVector::iterator it = Reader.Items->begin(); it != Reader.Items->end(); ++it) { *it ... } }   // libération automatique à la fin du bloc }

---

le typedef simplifie l'utilisation du type vector, cela donne un code plus rigoureux !

Ok je vais essayer �a, si �a peut rendre codeguard content ;)
Par contre un petit truc que je ne comprends pas quand m�me :

Citation:

---

CodeGuard sera content de voir que Allocation et Lib�ration sont effectu� du m�me c�t� !

---

Dans la modif que j'ai faite :

Code:

---

1 2	BOOL __stdcall mLgetFaults(TEventData* Buf, int& BufCount);

---

c'est bien l'appelant (mon exe) qui alloue et d�salloue le Buf !! Donc allocation et lib�ration sont bien fait du m�me c�t� !!
Donc il ne devrait pas r�ler ???

Normalement, il ne devrait pas r�ler effectivement !
Que contient TEventData ? Des AnsiString ? des TDynArray ? d'autres vecteur ?
Comment affecte tu le contenu de *Buf ? Affectation d'une variable locale ? Copie M�moire ?

Si tu retires le destructeur, il r�le quand m�me car un destructeur vide n'a pas d'utilit� !

Tient j'avais aussi fait d�lirer CodeGuard : Thread et DLL : probl�me de #define, il semblait perturb� si je chargeais une DLL juste apr�s en avoir d�charg� une autre !

Bien vu, TEvenData contient un map !! :roll:
Sinon il contient des String.
Et le contenu de *Buf et affecter par variable locale.

Par contre il ne r�le plus avec ce type d'appel (avec allocation et d�sallocation dans la dll bien sur) :

Code:

---

1 2	TEventData* mLgetFaults(int& bufferCount)

---

sauf si dans mon exe je recopie mes TEventData (dans un vector bien s�r...)

Cela peut �tre li� au compteur de r�f�rence des chaines
En fait l'affectation d'un String (RTL), augmente un compteur de r�f�rence, la lib�ration, le d�cr�mente, il est possible que le compteur tombe a z�ro du mauvais c�t� d'o� l'erreur !

Pour les vecteurs, je ne ma�trise pas du tout leur fonctionnemment m�moire

Dans mes habitudes, TEventData ne contiendrait que des types API comme char*, char[] ou BSTR mais pas de type objet, cela �vite ce genre de soucis, et cela rend la DLL compatible avec plus de langage

oui en pratique il y aura une "surcouche" avec des types simples car ma dll devra �tre utilis�e par une autre appli en .NET
Mais je ne pensais pas me servir de cette surcouche pour mon appli puisque elle est aussi en C++ avec le m�me compilo, mais peut �tre que je le ferai apr�s tout vu que �a ne semble pas si simple d'�changer proprement tous types d'objets...

Encore une fois un grand merci � toi pour ton temps et tes pr�cieux conseils :P