Discussion :

[vinny_the_true]

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

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

[vinny_the_true]

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

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 ?

[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!

[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

Il va falloir que je me penche sérieusement sur tout ça moi, pas évident

[JolyLoic]

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.

[vinny_the_true]

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

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"

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

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