MFC liées statiquement fonctionnent en DEBUG, pas en RELEASE

Version imprimable

Bonjour,

Mon application utilise les DLL MFC liées statiquement.

En debug, cela fonctionne bien. En release cela plante...

Au moment de l'Initinstance j'ai :

Code:

1
2
3
4
5
 
	CCommandLineInfo cmdInfo;
	ParseCommandLine(cmdInfo);
	if (!ProcessShellCommand(cmdInfo))
		return FALSE;

Lors du passage dans la fonction ProcessShellCommand() il créé un nouveau fichier au moyen de la fonction : CDocManager::OnFileNew();
Après plusieurs opérations, il tombe dans la fonction suivante :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
/////////////////////////////////////////////////////////////////////////////
// CSingleDocTemplate commands
 
CDocument* CSingleDocTemplate::OpenDocumentFile(LPCTSTR lpszPathName,
	BOOL bMakeVisible)
	// if lpszPathName == NULL => create new file of this type
{
	CDocument* pDocument = NULL;
	CFrameWnd* pFrame = NULL;
	BOOL bCreated = FALSE;      // => doc and frame created
	BOOL bWasModified = FALSE;
 
	if (m_pOnlyDoc != NULL)
	{
		// already have a document - reinit it
		pDocument = m_pOnlyDoc;
		if (!pDocument->SaveModified())
			return NULL;        // leave the original one
 
		pFrame = (CFrameWnd*)AfxGetMainWnd();
		ASSERT(pFrame != NULL);
		ASSERT_KINDOF(CFrameWnd, pFrame);
		ASSERT_VALID(pFrame);
	}
	else
	{
		// create a new document
		pDocument = CreateNewDocument();
		ASSERT(pFrame == NULL);     // will be created below
		bCreated = TRUE;
	}
 
	if (pDocument == NULL)
	{
		AfxMessageBox(AFX_IDP_FAILED_TO_CREATE_DOC);
		return NULL;
	}
	ASSERT(pDocument == m_pOnlyDoc);
 
	if (pFrame == NULL)
	{
		ASSERT(bCreated);
 
		// create frame - set as main document frame
		BOOL bAutoDelete = pDocument->m_bAutoDelete;
		pDocument->m_bAutoDelete = FALSE;
					// don't destroy if something goes wrong
		pFrame = CreateNewFrame(pDocument, NULL);
		pDocument->m_bAutoDelete = bAutoDelete;
		if (pFrame == NULL)
		{
			AfxMessageBox(AFX_IDP_FAILED_TO_CREATE_DOC);
			delete pDocument;       // explicit delete on error
			return NULL;
		}
	}

Et il provoque in assert sur le AfxMessageBox(AFX_IDP_FAILED_TO_CREATE_DOC);

En liant les MFC dynamiquement cela fonctionne bien...
Si quelqu'un aurait une idée de la raison du plantage...

11/05/2009, 18h38
bacelar

Quelle ligne ?
Quelle erreur (le debuggeur le dit)?
Toutes les librairies et dll sont en Release ?

etc...
11/05/2009, 18h40
JSmey

Bonjour bacelar,

Sorry j'avais appuyé sur la mauvaise touche (entre créer et visualiser) et j'avais donc posté un message pas complet.

Pour info, tout est en release oui.
11/05/2009, 20h06
bacelar

Je signale que l'on peut faire du pas à pas sous VS, même en Release.
Il faut juste générer les pdb.

Donc en débuggant en mode pas à pas en Release, ça donne quoi ?
12/05/2009, 00h01
JSmey

Oui je suis en mode pas-à-pas en Release...

Ben cela fait ce qui est dit au début.
12/05/2009, 08h34
farscape

salut,
tu utilises VC2008 ?

Bonjour Farscape,

Oui j'utilise bien VS2008. Je suis le collègue d'Alen, et l'application est dérivée des échanges que vous avez eu fin de l'année passé (migration d'une application vers le look "Office 2007").
Pour info le code de InitInstance..

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
/////////////////////////////////////////////////////////////////////////////
// CTASelectApp initialization
BOOL CTASelectApp::InitInstance()
{

...
	// InitCommonControlsEx() est requis sur Windows*XP si le manifeste de l'application
	// spécifie l'utilisation de ComCtl32.dll version*6 ou ultérieure pour activer les
	// styles visuels.  Dans le cas contraire, la création de fenêtres échouera.
	INITCOMMONCONTROLSEX InitCtrls;
	InitCtrls.dwSize = sizeof(InitCtrls);
	// À définir pour inclure toutes les classes de contrôles communs à utiliser
	// dans votre application.
	InitCtrls.dwICC = ICC_WIN95_CLASSES;
	InitCommonControlsEx(&InitCtrls);

	CWinAppEx::InitInstance();

	// Initialiser les bibliothèques OLE
	if (!AfxOleInit())
	{
		AfxMessageBox(IDP_OLE_INIT_FAILED);
		return FALSE;
	}

	EnableLoadWindowPlacement(FALSE);

	/////////////////////////////////////////////////////////////////////////
	// Standard initialization
	// If you are not using these features and wish to reduce the size
	//  of your final executable, you should remove from the following
	//  the specific initialization routines you do not need.

	LoadStdProfileSettings(0);  // Load standard INI file options
	InitContextMenuManager();
	InitKeyboardManager();
	InitTooltipManager();
	CMFCToolTipInfo ttParams;
	ttParams.m_bVislManagerTheme = TRUE;
	TASApp.GetTooltipManager()->SetTooltipParams(AFX_TOOLTIP_TYPE_ALL,
		RUNTIME_CLASS(CMFCToolTipCtrl), &ttParams);
	// Inscrire les modèles de document de l'application. Ces modèles
	//  lient les documents, fenêtres frame et vues entre eux
	CSingleDocTemplate* pDocTemplate;
	pDocTemplate = new CSingleDocTemplate(
		IDR_MAINFRAME,
		RUNTIME_CLASS(CTASelectDoc),
		RUNTIME_CLASS(CMainFrame),       // fenêtre frame SDI principale
		RUNTIME_CLASS(CTASelectView));
	if (!pDocTemplate)
		return FALSE;
	AddDocTemplate(pDocTemplate);

	// Enable DDE Execute open
	EnableShellOpen();
	RegisterShellFileTypes(TRUE);
	
	// Update registry with ftp parameters 
....

	// Parse command line for standard shell commands, DDE, file open
	CCommandLineInfo cmdInfo;
	ParseCommandLine(cmdInfo);

	// Dispatch commands specified on the command line. Retournent FALSE si
	// l'application a été lancée avec /RegServer, /Register, /Unregserver ou /Unregister.
	if (!ProcessShellCommand(cmdInfo))
		return FALSE;

Merci

12/05/2009, 10h52
bacelar

Si vous faite du pas à pas, pourquoi ne pas donner la ligne exacte ?
Pourquoi ne pas donner les valeurs des variables utilisées par la ligne qui pose problème ?
Pourquoi ne pas avoir les informations produites par le débuggeur ?

Sur un code de plusieurs dizaines de ligne, cela permet de gagner beaucoup de temps.

Bonjour Bacelar,

Comme marqué plus haut il fait un assert sur le AFX_IDP_FAILED_TO_CREATE_DOC:
Code:

1 2 3 4 5 6 7 8 9 pFrame = CreateNewFrame(pDocument, NULL); pDocument->m_bAutoDelete = bAutoDelete; if (pFrame == NULL) { AfxMessageBox(AFX_IDP_FAILED_TO_CREATE_DOC); delete pDocument; // explicit delete on error return NULL; }
En regardant le code cela arrive parce que pFrame == NULL... la fonction CreateNewFrame ne fonctionne pas comme elle devrait.
Si je fais du step par step dans cette fonction cela fonctionne bien jusqu'à la sortie de la fonction, à ce moment la valeur transmise est nulle alors que le return pPointer est bien initialisé...

J'espère avoir été plus clair comme ça.

12/05/2009, 11h47
bacelar
C'est bizarre:
le code de la méthode "CDocTemplate::CreateNewFrame" termine par
Code:

1 2 // it worked ! return pFrame;
Quelle version des MFC utilisez-vous ?

En Release, il ne faut pas avoir une confiance aveugle dans le débuggeur.
S'il y a des choses étranges, utilisez le code assembleur en mode pas à pas pour vérifier le contenue des "variables" et des registres.
12/05/2009, 12h01
farscape

je pense que c'est un problème de contexte,
sur le projet qui m'a servi de départ je constate le même problème que toi en release en mode static.
sur un autre projet, celui que j'ai réalisé pour mon dernier tuto sur les MFC le problème n'apparait pas.
je regarde de mon coté si je trouve quelque chose expliquant cela .
12/05/2009, 12h10
bacelar

Si c'est un problème de contexte, n'y aurait-il pas une modification sur une lib pour faire passer les MFC en static qui n'a pas été répercuté en Release ?
12/05/2009, 16h45
JSmey

Heuuu,

je ne sais pas :roll:

Si oui, je ne sais pas quoi...
12/05/2009, 16h51
bacelar

Pouvez-répondre à mes questions précédentes ? (version des MFC etc...)
12/05/2009, 17h32
JSmey

Les MFC 9.

Citation:

En Release, il ne faut pas avoir une confiance aveugle dans le débuggeur.
S'il y a des choses étranges, utilisez le code assembleur en mode pas à pas pour vérifier le contenue des "variables" et des registres.

C'est ce que j'avais cru comprendre alors je suis aussi passé en mode assembleur mais cela ne donnait pas de meilleurs résultats.

Strange tout ça.
12/05/2009, 18h26
bacelar

Etes-vous sûr de ne pas faire un mixe de version de MFC ?

Je m'explique, je suis sur une machine n'ayant que VC2008 SP1, donc les MFC 9.0, et la fin du code de la méthode "CDocTemplate::CreateNewFrame" ne semble pas être identique à la votre.

En suivant l'assembleur, normalement on ne peu pas perdre la valeur du pointeur de fenêtre qui est soit stocker dans un registre, soit dans la pile.
Avec cette information, il faut analyser le code machine de l'appelant en charge de récuperer ce pointeur.
S'il vas le chercher au mauvais endroit, il y un problème de version de MFC ou des constantes de compilations en vrac.
14/05/2009, 15h20
JSmey

Je travaille sur une machine Vista (récemment formatée) avec VS2008 SP1. Je n'ai rien installé d'autre...

Je ne pense donc pas avoir de mixe entre les MFC.

...
14/05/2009, 16h14
bacelar
Pouvez-vous nous donner le code source de la méthode "CDocTemplate::CreateNewFrame" depuis l'affichage dans le debuggeur.
Je n'ai pas la même fin de méthode que vous.

j'ai :
Code:

1 2 // it worked ! return pFrame;
et non :

Code:

return pPointer

Voila le bout de code :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
/////////////////////////////////////////////////////////////////////////////
// Default frame creation
 
CFrameWnd* CDocTemplate::CreateNewFrame(CDocument* pDoc, CFrameWnd* pOther)
{
	if (pDoc != NULL)
		ASSERT_VALID(pDoc);
	// create a frame wired to the specified document
 
	ASSERT(m_nIDResource != 0); // must have a resource ID to load from
	CCreateContext context;
	context.m_pCurrentFrame = pOther;
	context.m_pCurrentDoc = pDoc;
	context.m_pNewViewClass = m_pViewClass;
	context.m_pNewDocTemplate = this;
 
	if (m_pFrameClass == NULL)
	{
		TRACE(traceAppMsg, 0, "Error: you must override CDocTemplate::CreateNewFrame.\n");
		ASSERT(FALSE);
		return NULL;
	}
	CFrameWnd* pFrame = (CFrameWnd*)m_pFrameClass->CreateObject();
	if (pFrame == NULL)
	{
		TRACE(traceAppMsg, 0, "Warning: Dynamic create of frame %hs failed.\n",
			m_pFrameClass->m_lpszClassName);
		return NULL;
	}
	ASSERT_KINDOF(CFrameWnd, pFrame);
 
	if (context.m_pNewViewClass == NULL)
		TRACE(traceAppMsg, 0, "Warning: creating frame with no default view.\n");
 
	// create new from resource
	if (!pFrame->LoadFrame(m_nIDResource,
			WS_OVERLAPPEDWINDOW | FWS_ADDTOTITLE,   // default frame styles
			NULL, &context))
	{
		TRACE(traceAppMsg, 0, "Warning: CDocTemplate couldn't create a frame.\n");
		// frame will be deleted in PostNcDestroy cleanup
		return NULL;
	}
 
	// it worked !
	return pFrame;
}

Chez moi cela se termine aussi par :

Code:

1
2
// it worked !
	return pFrame;

14/05/2009, 17h53
bacelar

En mode pas à pas dans le debuggeur "pFrame" n'est pas NULL sur la ligne du return ?
Sinon, le problème vient d'une des lignes précédentes qui met cette valeur à NULL.

Si elle n'est pas NULL, vérifiez le code assembleur de la ligne du return pour vérifier comment la valeur de retour est passée à la méthode appelante (par registre ou sur la pile).
Une fois dans le code de la fonction appelante (après l'exécution de l'op-code ret), vérifiez où le code de la fonction appelante va chercher la valeur de retour.
Si le code va la chercher à un autre endroit, vous avec des problèmes de configuration de compilation et d'édition de lien qui sont incohérentes entre les modules de compilations (lib, lib de dll et exécutable).
29/05/2009, 09h41
JSmey

Bonjour,

Merci Bacelar pour tes conseils.

J'ai finalement trouvé le problème !!! En fait les DLL étaient bien liées statiquement mais dans les paramètres du projet, dans Preprosessor definitions : les DLL étaient définies comme liées dynamiquement. Cela créait un conflit qui s'est résolu en supprimant la définition.

Bonne continuation.