Problème de migration MFC Dynamic linked to static

Version imprimable

23/08/2006, 14h52
alen

Problème de migration MFC Dynamic linked to static

Bonjour
J'essaye de sous VC2005 de lier les MFC de manière statique à mon projet, celle-ci étaient auparavant déclarées comme étatnt dynamique.
J'ai donc dans les propriétés du projet sélectionné "Use MFC in a Static Library" et après avoir recompilé tout le projet cela fonctionne.... enfin presque je ne sais plus imprimer ni faire un apercu avant impression, l'application crash avec une corruption du heap.
Le crash survient dans COccManager::PostCreateDialog (occmgr.cpp) lorque le système essaye de libérer la mémoire allouée pour
pDlgInfo->m_ppOleDlgItems.
Avez-vous une idée?
23/08/2006, 14h56
rigobert

est-ce que tu as changé de version de MFC par la même occasion ou pas ?
23/08/2006, 15h05
alen

Oui mon apllication est déjà ancienne (VC6), j'avais migré sur VC2003 il y a deux ans en gardant les MFCs en dll partagée (MFC7), maintenant je suis passé sur VC2005 et pour des raisons de mise à jour je voudrais lier les nouvelles MFC (8) de manière statique.
23/08/2006, 15h13
farscape

salut,
dans ton programme tu utilises des dll autres que celles des MFC?
tu n'as pas touché a l'alignement memoire ?
sinon peut etre bien que tu as un bug memoire mis en evidence par vc2005...
:D
23/08/2006, 15h19
rigobert

Personnellement j'aurais regénéré un projet de zéro avec le nouveau wizard et recollé le code utilisateur à la main, de façon à repartir sur des bases solides (il y a eu pas mal de changements dans les MFC depuis VC6).

Ca prend un peu de temps, c'est fastidieux, mais par expérience (nombreuses migrations VC6 -> VC7 réussies sans aucune prise de tête) je peux t'affirmer qu'à moyen terme c'est un très bon investissement.

Maintenant si c'est un (petit) projet qui ne sera de toute façon jamais pérennisé, c'est autre chose...
23/08/2006, 15h20
alen

J'utilise d'autres dll, ce qui me rend perplexe c'est que si je repasse en liaison dynamique pour les MFCs, que je recompile le projet j'ai de nouveau accès à l'impression sans plantage 8O
23/08/2006, 15h26
alen

Citation:

Envoyé par rigobert

Personnellement j'aurais regénéré un projet de zéro avec le nouveau wizard et recollé le code utilisateur à la main, de façon à repartir sur des bases solides (il y a eu pas mal de changements dans les MFC depuis VC6).

Ca prend un peu de temps, c'est fastidieux, mais par expérience (nombreuses migrations VC6 -> VC7 réussies sans aucune prise de tête) je peux t'affirmer qu'à moyen terme c'est un très bon investissement.

Maintenant si c'est un (petit) projet qui ne sera de toute façon jamais pérennisé, c'est autre chose...

Oups je ne pense pas que ce soit vraiment possible, c'est un projet qui à démarré en 2000, c'est une appli avec plus de 300 fichiers cpp, le fichier de resource comporte 16 langues...
23/08/2006, 15h27
farscape

Alors attention aux problèmes suivant :
Mélange de CRT statique et dynamique ne font pas bon ménage …
Surtout sur des objets pouvant être libérés dans un module autre que celui qui l’a construit.
Les dll et .lib doivent être reconstruite avec Visual 2005 pour éviter ce même problème.
Voir mon tuto sur la migration. http://farscape.developpez.com/tutor...on-vc6-vc2005/

Et ce post :
http://www.developpez.net/forums/sho...72#post1047972
:D
23/08/2006, 16h12
alen

Citation:

Envoyé par farscape

Alors attention aux problèmes suivant :
Mélange de CRT statique et dynamique ne font pas bon ménage …
Surtout sur des objets pouvant être libérés dans un module autre que celui qui l’a construit.
Les dll et .lib doivent être reconstruite avec Visual 2005 pour éviter ce même problème.
Voir mon tuto sur la migration. http://farscape.developpez.com/tutor...on-vc6-vc2005/

Et ce post :
http://www.developpez.net/forums/sho...72#post1047972
:D

Merci pour l'info très bien réalisée et très interressante. Je n'était donc pas le seul à avoir passé des heures à la conversion de prj ;)
Je penche pour un problème de mélange de CRT statique et dynamique, mais comment le localiser? le problème survient lorsque j'appelle CView::OnFilePrintPreview() une idée?
23/08/2006, 17h40
farscape

ben difficile de repondre comme ça :
mais il faut traquer les fonctions utilisées dans les dll et voir si elles ferment/alterent des objets ou ressources (fichier etc) allouées dans le thread principal.

mais bon je te conseille de loin d'unifier le tout en dll partagées ...
la distribution des dll n'est pas si compliquée que ça ..

tu as verifié ton alignement memoire ?
que tout tes modules sont produits par vc2005 ?
:D
24/08/2006, 08h50
alen

Citation:

Envoyé par farscape

tu as verifié ton alignement memoire ?
que tout tes modules sont produits par vc2005 ?
:D

J'ai recompilé mes dll avec vc2005, par contre j'utilise des ActiveX comme FPSpread, TChart, commX qu'evidemment je ne peux recompiler. Mais bon je ne pense pas qu'il y aie des allocations mémoire partagée

Pour l'alignement mémoire, j'utilise également des CImageList, mais je n'ai pas explicitement modifié dans mon code l'alignement mémoire. Dans les propriété du projet "Struct member alignment" est sur default.

Je vais passer mon projet(version précédente) en static sur vc2003, histoire de voir si le problème était déjà présent ou si effectivement il est provoqué par l'utilisation des MFC8.
24/08/2006, 11h01
alen

Quelques infos supplémentaires le crash survient en Debug et en Release dans la creation de la CPrintingDialog. Je met une copie du Trace au cas ou ce serait éclairant pour vous, pour moi pas trop...
cela fait fort penser à un probleme d'alignement mémoire, le crash survient à la libération d'une zone allouée. Si c'est cela ce que je ne comprend pas c'est pourquoi cela ne se produit pas lorsque les dll sont linkées dynamiquement

--->CRASH corruption du heap
free(void * pBlock=0x7c91fb71) Line 110 C
COccManager::PostCreateDialog(_AFX_OCC_DIALOG_INFO * pDlgInfo=0x0012e460) Line 237 + 0x6 bytes C++
CWnd::CreateDlgIndirect(const DLGTEMPLATE * lpDialogTemplate=0x00000000, CWnd * pParentWnd=0x02611250, HINSTANCE__ * hInst=0x00400000) Line 323 C++
CDialog::CreateIndirect(const DLGTEMPLATE * lpDialogTemplate=0x00000000, CWnd * pParentWnd=0x02611250, void * lpDialogInit=0x00000000, HINSTANCE__ * hInst=0x00400000) Line 210 + 0x17 bytes C++
CDialog::CreateIndirect(void * hDialogTemplate=0x00000000, CWnd * pParentWnd=0x02611250, HINSTANCE__ * hInst=0x00400000) Line 188 + 0x12 bytes C++
CDialog::Create(const char * lpszTemplateName=0x00007802, CWnd * pParentWnd=0x02611250) Line 171 C++
CPrintingDialog::CPrintingDialog(CWnd * pParent=0x02611250) Line 27 C++
CView::OnFilePrint() Line 217 + 0xc bytes C++
CRightViewSelP::Print() Line 58 + 0x16 bytes C++
24/08/2006, 11h03
Médinoc

Ce que je trouve bizarre, c'est que ça se produise aussi en Release. Mais la cause, je pense la connaitre : La condition "Ce qui est alloué par un module est désallouer par ce même module" n'est pas respectée...
24/08/2006, 11h05
farscape

au niveau de l'option bibliotheque de runtime tu a mis quoi ?
tu devrais avoir/MT dans tous tes modules

:D
24/08/2006, 12h07
alen

Citation:

Envoyé par farscape

au niveau de l'option bibliotheque de runtime tu a mis quoi ?
tu devrais avoir/MT dans tous tes modules

:D

J'ai bien /MT partout
24/08/2006, 12h30
alen

:oops:
J'ai trouvé le problème, rien à voir avec MFC8, juste simplement afxprint.rc manquant dans les resources, donc l'appli faisait appel à des strings non existantes....
Merci à tous pour votre aide
24/08/2006, 12h44
alen

En fait l'éditeur de resource de VC2005 a enlevé les lignes

#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
#ifdef _WIN32
LANGUAGE 9, 1
#pragma code_page(1252)
#endif //_WIN32
#include "res\Phoenix.rc2" // non-Microsoft Visual C++ edited resources
#include "afxres.rc" // Standard components
#include "afxprint.rc" // printing/print preview resources
//#endif

et de fait afxprint.rc n'est plus inclus dans le projet. Quel est la bonne manière en VC2005 pour inclure ce fichier?
24/08/2006, 13h26
Médinoc

Pourquoi pas dans le fichier .rc2 de ton projet ?