debug assertion failed sur un delete venant d'une DLL

Bonjour,

J'ai un problème qui apparait, et là c'est le comble, qu'en mode Debug... lol

En fait, j'utilise des DLL et je crée des objets à partir de classes qui sont dans ces DLL...

Et apparemment, c'est le delete de ces objets qu'il n'aime pas...

J'ai mis exactement ce code, ou le delete suit le new... donc impossible que le pointeur ait été changé, et le pointeur n'est effectivement pas NULL !

Code:

---

1 2 3

Header* h = new Header(); delete h; // C'est la que ca plante

---

J'obtiens l'erreur : Debug Assertion Failed!
File: dbgheap.c
Line: 1044
...

J'avais trouvé ce post qui en parlait :
http://www.developpez.net/forums/d89...ile-dbgheap-c/
ou quelqu'un disait qu'avec les DLL, si on a des free, delete, il faut voir le runtime library qu'on utilise si on a ce problème... mais j'ai un peu tout essayé comme config dans les settings... et ca n'a rien changé...

Quelqu'un a une idée ?

Merci
++

Primo : c'est une très mauvaise idée d'avoir la possibilité d'instancier les objets d'une classe implémentée dans une DLL, justement pour des problèmes de compatibilité de runtimeC.

Secondo : Comme ont ne connait pas la version de la C-Runtime ou du compilateur ou du SDK que vous utiliez, le numéro de ligne, ça nous fait une belle jambe. Donnez nous le source de la ligne si nécéssaire.

Tercio : Comme c'est un assert, la cause de l'erreur devrait être évidente car elle correspond au non respect d'une contrainte que la MACRO ASSERT est chargé de vérifier (en Debug). Comme on n'a pas la ligne de code, c.f. Secondo, et bien on ne peut pas vous aider.

En résumé, avant de chercher une solution, analysez le problème.

P.S.: et donnez nous cette putain d'assertion (le code) qui est fausse.

Ce qui est créé par une DLL doit être détruit par la même DLL.

non mais ce n'est pas créer par la DLL...

En fait, j'ai mes .h de ce qu'il y a dans la DLL, et je lie donc mon programme avec cette DLL pour que lors de l'execution, il aille chercher le code dedans.

Mais en fait, c'est dans mon programme, que je fais :

Code:

---

1 2	Header* h = new Header(); delete h; // C'est la que ca plante

---

Et c'est la ligne du delete qui stoppe le programme, encore une fois, que en mode DEBUG...

Je ne vois pas quel autre code source je peux donner ?


Parce que en fait, moi ce que je voulais faire, c'est vraiment définir des classes que je mets dans des DLL et après dans mes programmes, pouvoir créer mes objets de ces types la... donc apparemment il ne faudrait pas le faire ?
Ou alors passer par 2 fonctions de la DLL qui créer un objet et le supprime ? Au lieu de passer par un new et delete direct... ?

Merci
Bonne journée

Citation:

---

Envoyé par italiasky

Ou alors passer par 2 fonctions de la DLL qui créer un objet et le supprime ? Au lieu de passer par un new et delete direct... ?

---

Quand on joue avec des classes C++ dans des DLL, c'est toujours la méthode que je conseille.

Oui donc c'est bien ce que je pensais, à proscrire les new et delete direct...

Mais pourquoi en mode release ca ne plante pas ? Si il y a vraiment un problème ?

Le problème, c'est que les DLL que j'utilise sont utilisées par pas mal d'autres logiciels dont je ne connais même pas l'existence... lol et donc si je modifie le code de ces DLL pour ajouter des fonction intermédiaires pour créer et détruire les objets, ca va poser problème, parce que le jour ou on me mets les .dll d'avant, ca va planter... ces nouvelles méthodes n'existeront pas...

Vu que le problème n'intervient qu'en mode DEBUG, n'est-il pas possible de le contourner juste pour le debug ? Une option ? Vu qu'à priori ce n'est pas un réel problème en soi, enfin pas un problème de fuite de mémoire non ? Sinon mon programme cracherait en mode release... ?

Merci de votre aide, je suis un peu coincé la du coup... :aie:

Le destructeur de la classe est-il virtuel?
Cette classe alloue-t-elle quelque chose qu'elle libérerait dans son destructeur?

Oui son destructeur est virtuel.

Et oui, dans son destructeur, elle libère des choses...

Dans son constructeur, elle a créé :

Code:

---

StructMess mess = new StructMess[nbr];

---

Et dans le destructeur :

Code:

---

delete[] mess;

---

une piste... ? :roll:

Y'a des chances: Si le constructeur est inline en plus, alors il n'est pas exécuté dans la DLL, mais dans l'EXE. Donc, on se retrouve avec l'exe qui fait l'allocation, la DLL qui fait la libération, d'où plantage.

Il faut s'assurer que le constructeur et le destructeur de la classe soient tous les deux exécutés par la DLL et rien d'autre.

Citation:

---

Envoyé par Médinoc

Il faut s'assurer que le constructeur et le destructeur de la classe soient tous les deux exécutés par la DLL et rien d'autre.

---

Et c'est possible ? Comment on peut vérifier ca ? 8O


Mais pour le constructeur, il n'a pas l'air inline... Enfin je ne sais peut être pas trop, mais comment on peut savoir ca aussi ?


Merci pour ton aide ;)

Est-ce que tu es allé pas à pas avec le debogeur pour trouver où ce situe exactement la panne.

Oui j'ai bien été pas à pas et j'ai bien vu que c'était le delete qui causait le probleme...

Enfin, j'ai trouvé comment pallier le problème, en passant par une classe intermédiaire :

Code:

---

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

template <class T> class DLLFix : public T { public: DLLFix(); virtual ~DLLFix(); };   template<class T> DLLFix<T>::DLLFix<T>() {}   template<class T> DLLFix<T>::~DLLFix<T>() {}

---

Et la je n'ai plus de problèmes apparemment...

Merci à vous
++

Re, petite précision qui aurait besoin d'une confirmation...

Le problème que j'observais, c'était parce que la DLL était faite un peu bizarre je trouve...
C'est à dire, qu'on utilisait les .h et le .lib de la DLL mais nulle part ce qu'il y avait dedans était exporté et donc réimporté après dans le programme client...

Parce que, j'ai essayé en créant une petite DLL dans laquelle j'exporte la classe avec la méthode du __declspec(ddlexport)
Et dans le programme client, je mets le .h, le .lib et donc la définition du __declspec(ddlimport)

Le new et le delete de mon objet ne pose pas de problème...

Donc est-ce que quelqu'un peu confirmer que c'était le fait aussi que il n'y avait aucune information d'exportation puis de réimportation de la classe qui faisait crashé le programme client au moment du delete ? Ou alors, j'ai encore zappé un truc...

Merci
++

Cette histoire d'information n'aurait pas dû changer grand-chose, les infos correspondantes étant dans le .lib.