Commençons par comprendre l'allocation de tas et la pile sur le système d'exploitation Windows par rapport à nos applications/DLL. Traditionnellement, le système d'exploitation et les bibliothèques d'exécution sont livrés avec une implémentation du tas.
- Au début d'un processus, le système d'exploitation crée un tas par défaut appelé Process heap. Le tas de processus est utilisé pour allouer des blocs si aucun autre tas n'est utilisé.
- Les temps d'exécution du langage peuvent également créer des tas séparés au sein d'un processus. (Par exemple, l'environnement d'exécution C crée son propre tas.)
- Outre ces tas dédiés, le programme d'application ou l'une des nombreuses bibliothèques de liens dynamiques (DLL) chargées peut créer et utiliser des tas séparés, appelés tas privés
- Ces tas se trouvent au-dessus du gestionnaire de mémoire virtuelle du système d'exploitation dans tous les systèmes de mémoire virtuelle.
- Parlons plus en détail du CRT et des tas associés :
- Allocateur d'exécution C/C++ (CRT) :fournit malloc() et free() ainsi que les opérateurs new et delete.
- Le CRT crée un tel tas supplémentaire pour toutes ses allocations (le descripteur de ce tas CRT est stocké en interne dans la bibliothèque CRT dans une variable globale appelée _crtheap) dans le cadre de son initialisation.
- CRT crée son propre tas privé, qui réside au-dessus du tas Windows.
- Le tas Windows est une fine couche entourant l'allocateur d'exécution Windows (NTDLL).
- L'allocateur d'exécution Windows interagit avec l'allocateur de mémoire virtuelle, qui réserve et valide les pages utilisées par le système d'exploitation.
Votre lien DLL et exe vers des bibliothèques CRT statiques multithreads. Chaque DLL et exe que vous créez a son propre tas, c'est-à-dire _crtheap. Les allocations et les désallocations doivent se produire à partir du tas respectif. Qu'un alloué dynamiquement à partir de la DLL ne peut pas être désalloué de l'exécutable et vice-versa.
Ce que tu peux faire? Compilez notre code dans les DLL et les exe en utilisant /MD ou /MDd pour utiliser la version spécifique au multithread et à la DLL de la bibliothèque d'exécution. Par conséquent, DLL et exe sont liés à la même bibliothèque d'exécution C et donc à un _crtheap. Les allocations sont toujours associées à des désallocations au sein d'un même module.
Les DLL / exe devront être liés à une implémentation de bibliothèques d'exécution C.
Dans le cas des bibliothèques C Windows Runtime, vous avez la possibilité de spécifier si vous souhaitez créer un lien vers les éléments suivants :
- Bibliothèque d'exécution C à thread unique (la prise en charge des bibliothèques à thread unique a été interrompue)
- DLL multithread / DLL de débogage multithread
- Bibliothèques d'exécution statiques.
- Peu de plus (vous pouvez vérifier le lien)
Chacun d'eux fera référence à un tas différent, vous n'êtes donc pas autorisé à transmettre l'adresse obtenue à partir du tas d'une bibliothèque d'exécution à l'autre.
Maintenant, cela dépend de la bibliothèque d'exécution C à laquelle la DLL dont vous parlez a été liée. Supposons, disons, que la DLL que vous utilisez a été liée à la bibliothèque d'exécution C statique et que votre code d'application (contenant la fonction principale) est lié à la DLL d'exécution C multithread, alors si vous passez un pointeur vers la mémoire allouée dans le DLL dans votre programme principal et essayez de la libérer ou vice-versa, cela peut conduire à un comportement indéfini. Ainsi, la cause première de base sont les bibliothèques d'exécution C. Veuillez les choisir avec soin.
Veuillez trouver plus d'informations sur les bibliothèques d'exécution C prises en charge ici et ici
Une citation de MSDN :
Attention Ne mélangez pas les versions statiques et dynamiques des bibliothèques d'exécution. Le fait d'avoir plusieurs copies des bibliothèques d'exécution dans un processus peut entraîner des problèmes, car les données statiques d'une copie ne sont pas partagées avec l'autre copie. L'éditeur de liens vous empêche de créer des liens avec des versions statiques et dynamiques dans un seul fichier .exe, mais vous pouvez toujours vous retrouver avec deux copies (ou plus) des bibliothèques d'exécution. Par exemple, une bibliothèque de liens dynamiques liée aux versions statiques (non DLL) des bibliothèques d'exécution peut causer des problèmes lorsqu'elle est utilisée avec un fichier .exe lié à la version dynamique (DLL) des bibliothèques d'exécution. . (Vous devez également éviter de mélanger les versions de débogage et non débogage des bibliothèques en un seul processus.)