Problème de tas avec une dll

Version imprimable

17/12/2006, 04h07
vinny_the_true

Problème de tas avec une dll

Bonjour à tous.

J'ai pas mal cherché sur ce forum et ailleurs, je ne trouve pas d'explication concernant les règles d'allocations/désallocation dynamique lorsqu'on a plusieurs tas, par exemple dans mon cas, avec une dll.

Dans mon cas, je m'assure que l'objet qui alloue, désalloue également, je pensais naïvement que ce serait suffisant pour éviter ces problèmes de tas, hors il semble que ce n'est pas le cas...
Il semblerait que ce ne soit pas non plus le code (code dll ou exe ?) qui "décide" du tas utilisé, puisque je peux faire sans Heap Corruption un delete sur mon device créé par la méthode de la dll.

Donc je suis un peu perdu et je n'arrive plus à désallouer un petit pointeur sans Heap Corruption.

Si vous avez besoin de plus d'infos pour m'aider, demandez, mais globalement je ne demande pas une solution à mon cas, mais plutôt qu'on me montre le chemin pour enfin comprendre ces rouages plus précisément :)
17/12/2006, 09h46
Laurent Gomila

La règle c'est que chaque module (processus ?) possède son tas, et que chaque désallocation doit se faire dans le module qui a fait l'allocation. Le fait que tu puisses passer outre cette règle sans plantage n'est pas un indicateur que c'est permis, c'est plutôt un coup de bol.

Pense également à utiliser la bibliothèque standard sous forme de DLL, si plusieurs de tes modules y font appel.

Après si tu as toujours des erreurs en suivant ces règles, il faudrait en savoir un peu plus sur ton code.
17/12/2006, 16h56
vinny_the_true

Citation:

Envoyé par Laurent Gomila

La règle c'est que chaque module (processus ?) possède son tas, et que chaque désallocation doit se faire dans le module qui a fait l'allocation.

Dans ce que tu dis ici, tu parles bien du code, pas d'une éventuelle instance ? En fait dans ma solution, j'ai un projet regroupant tous mes outils compilé en lib static. Deux autre projet (en schématisant, l'exe et la dll) dépendent de ce projet, je me retrouve donc avec le code "en double" (?) dans la dll et dans l'exe. Le problème pourrait venir de là ? (une instance créée dans la dll utilise le code dll à ce niveau puis une fois passée à l'exe, le code de ce dernier ?)

Citation:

Envoyé par Laurent Gomila

Pense également à utiliser la bibliothèque standard sous forme de DLL, si plusieurs de tes modules y font appel.

Compte-tenu de ce que j'ai dis au-dessus, compiler mes outils en dll pourrait regler le problème ? Ce serait alors cette dernière qui serait propriétaire de toutes les allocations de mes classes d'outils ?

Juste pour plus de précisions au cas où, la classe qui me pose problème est un SharedPtr, créé par du code de la dll, il est ensuite passé à du code de l'exe pour être détruit à cet endroit. Moi je pensais naïvement que c'était l'origine de l'instance (ici la dll) qui allait dicter le tas utilisé, mais il semble que ce soitle contexte du code, exact ?
17/12/2006, 16h59
Médinoc

Mince, si les SharedPtr sont des templates comme ceux de boost, il est probable les différentes instances utilisent du code des différents modules.
Et là, il est possible qu'un SharedPtr d'un module essaie de désallouer (dans son destructeur) quelque chose d'alloué dans un autre module. Et là, ça pète!
17/12/2006, 17h10
vinny_the_true

Hum... Je n'ai pas regardé en détail l'implémentation boost des sharedptr, là c'est la mienne (proche dans le concept)

En fait, mon problème actuel concerne l'instance comptant les ref, allouée/désallouée toujours à l'intérieur de la classe, donc toujours par le même module si je build en dll (puisque comme je l'ai dis au-dessus, linké par plusieurs modules), par contre, ta remarque m'a fait remarquer que ce n'est pas le cas avec l'instance "Sharedptrisée".... Là je crois que j'ai effectivement un problème de conception :?.

Merci de vos réponses en tout cas :D

Il va falloir que je me penche sérieusement sur tout ça moi, pas évident :aie:
17/12/2006, 17h13
JolyLoic

Citation:

Envoyé par Médinoc

Et là, il est possible qu'un SharedPtr d'un module essaie de désallouer (dans son destructeur) quelque chose d'alloué dans un autre module. Et là, ça pète!

Sauf que si on se lie avec les versions "multithread dll" des bibliothèques standard, les appels aux new et delete se font alors dans cette DLL, et non plus dans ton code ou celui de l'autre DLL, et il n'y a plus de problèmes.
17/12/2006, 17h16
vinny_the_true

Citation:

Envoyé par JolyLoic

Sauf que si on se lie avec les versions "multithread dll" des bibliothèques standard, les appels aux new et delete se font alors dans cette DLL, et non plus dans ton code ou celui de l'autre DLL, et il n'y a plus de problèmes.

Oula, tu m'intéresses là ! :lol:

Tu pourrais (ou Laurent qui en parlait également) m'en dire un peu plus ? En fait j'avoue avoir un peu de mal à voir ce qu'il faut comprendre dans "si on se lie avec les versions "multithread dll" des bibliothèques standard":oops:
17/12/2006, 18h32
JolyLoic

En gros, A alloue et B désalloue -> BOOM. Comment règler ça ?

On introduit C et on fait tout passer par lui :
A veut allouer, mais délègue l'allocation à C. B veut désallouer mais délègue la désallocation à C. Donc tout se passe dans C, ça va.

C'est ce qui se passe automatiquement pour new et delete quand on choisi les options de compilation mutlithread dll (/MD et /MDd de mémoire, mais on peut les setter dans l'IHM).

Par contre, attention, tous les modules doivent avoir été compilés ainsi pour que ça marche bien.
17/12/2006, 19h14
vinny_the_true

Merci pour ton explication, en fait j'avais compris la théorie, c'était la mise en oeuvre qui me posait problème.

Je viens de tester, et bien sûr ça fonctionne sans problème:P
Par contre maintenant il va falloir que je cherche à quoi correspondent exactement ces options de code generation au niveau implémentation histoire de comprendre ce que je fais :aie: