Discussion :

[AntoineGael]

Bonjour,

Comme tout le monde, je connais en gros le rôle des flags /MT et /MD pour le "code generation" dans VS++. Toutefois, je suis curieux de savoir ce qu'il se passe en interne si l'on choisit l'un ou l'autre, notamment pour comprendre un problème qui me bloque actuellement.

- j'ai une lib et sa DLL associée en /MT. Plus précisément, il s'agit de ChromiumEmbedded Framework (CEF)
- j'ai mon EXE en /MT qui utilise cette lib/dll
- j'ai une DLL à moi, en /MT évidemment, linkée aussi à CEF
Ma DLL reçoit en paramètre un objet issu de CEF, appelle une méthode de cet objet qui génère un objet CefString:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
MyDLL.cpp : 
bool MyFunction(CefObject* pObj)
{
    CefString str = pObj->createString();
    ...
    return(true);
}

Tout se passe bien jusqu'à la libération à la fin du scope de la fonction : il y a un assert sur _CrtIsValidHeapPointer. Cela indique que ma DLL appelle le destructeur de str qui cherche à libérer de la mémoire qui a été allouée dans heap différent du sien (celui de l'EXE à priori.. ou de la DLL CEF ?)
Lorsque je build en /MD, tout se passe bien.

Ma conclusion serait la suivante :
- en /MT, le chargement d'une DLL implique que l'EXE appelant et la DLL sont chacun dans leur zone mémoire et personne n'a le droit d'aller jouer dans le terrain de l'autre.
- en /MD, la DLL s'intègre naturellement dans l'espace mémoire de l'EXE et tout va bien lorsqu'il y a allocation/désallocation par l'un ou l'autre.

J'ai bon ou je raconte n'importe quoi ?
Avez vous des liens qui expliquent plus clairement ce qui se passe avec /MT et /MD ?

Merci
Antoine

[AntoineGael]

J'ai trouvé les explications...
Il m'a simplement fallu regarder la page MSDN de _CrtIsValidHeapPointer :
http://msdn.microsoft.com/en-us/libr...hh(VS.80).aspx
Notamment :

The _CrtIsValidHeapPointer function is used to ensure that a specific memory address is within the local heap. The local heap refers to the heap created and managed by a particular instance of the C run-time library. If a dynamic-link library (DLL) contains a static link to the run-time library, it has its own instance of the run-time heap, and therefore its own heap, independent of the application's local heap.