[MFC] Probl�me Release/Debug

**Denn's** · 25/06/2007, 10h27

Bonjour,

Je d�veloppe une appli sous VC++6.0 et lorsque je la compile en mode Release je rencontre les probl�mes suivants:

=> Lorsque je clic droit/gauche sur un treeview, j'ai des plantages al�atoires alors qu'en mode debug, je ne les ai pas .

=> Tjours dans mes TreeViews, dans les label des noeuds de l'arbre, j'ai des caract�res �xotiques qui s'ajoutent.

Quelqu'un a-t-il d�ja rencontr� ce probl�me ?

**syn42** · 26/06/2007, 11h44

Bonjour,

A mon avis, tes probl�mes sont li�s.

La grosse diff�rence entre le mode d�bug et release est l'initialisation des variables. Donc v�rifie bien leur initialisations.

**Denn's** · 27/06/2007, 17h24

�a n'a pas l'air d'inspirer grand monde.....

**farscape** · 27/06/2007, 18h25

Envoy� par syn42

Bonjour,

A mon avis, tes probl�mes sont li�s.

La grosse diff�rence entre le mode d�bug et release est l'initialisation des variables. Donc v�rifie bien leur initialisations.

c''est d�j� une piste a �tudier.
utilise aussi des objets string ou CString pour manipuler les chaines ,ce genre de probl�me me fait penser � la manipulation erron�e de chaine de caract�res ...
je rajouterai que fonctionner en debug n'est pas une garantie de non bugs...

**Denn's** · 02/07/2007, 09h32

Du neuf:

Mode Debug => no problem
Mode Release:
=> MFC in a Shared DLL : le probl�me en question ( caract�res bizzares et plantages al�atoires )
=> MFC in a Static Library: Nickel comme le mode Debug.

Je pourrai m'en tenir l� mais je voudrais faire un ex�cutable assez compact or si je le mets en "MFC Static Library", il ne double pas de volume ms presque.
Que vaut-il mieux privil�gier ?
Les pros ( SSII, editeur de logiciel.... ) ,que font-ils , Static library ou Shared Library ? Sachant que l'�x�cutable devra �tre lanc� par le r�seau et ce d'une machine aussi bien XP que win2K ou Vista ?

**farscape** · 02/07/2007, 09h36

si tu as des plantages en mode MFC in a Shared DLL
c'est que tu dois utiliser plusieurs versions de la lib CRT dans ton programme...
(entre ton programme et tes .lib).

**Denn's** · 02/07/2007, 09h53

Mais encore ?!

**Denn's** · 03/07/2007, 08h57

info suppl�mentaire:

lors des plantages, le msg d'erreur est du genre:

"unexpected handle..etc,...la m�moire ne peut pas �tre Written etc".

C'est quoi la lib CRT ?
C'est la version de la dll MFC?

Dans les Project->Settings, j'ai compar� les param�tres Debug et Release, et apparement, il n'y a pas grosse diff�rence. Est-ce qu'il y a des param�tres de 'build' particuliers � prendre en compte ?

**farscape** · 03/07/2007, 09h10

salut,
la crt : console runtime library s'occupe entre autre des allocations m�moire : new ,free ,malloc etc..
http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx

le fait d'utiliser des versions diff�rentes de cette biblioth�que dans un programme cause des probl�mes si par exemple un module essaye de lib�rer de la m�moire allou�e par un autre module crt...
exemple : une chaine pass�e en argument dans un dll qui lib�re le pointeur.
si les deux modules n'utilisent pas la m�me crt �a plantera...
tu dois commencer par v�rifier ce point.

**Denn's** · 03/07/2007, 14h55

Salut,

A quoi puis-je voir que j'utilise pls CRT diff�rents ?

**Denn's** · 10/07/2007, 15h52

Dans mon application, j'utilise des listes chain�es dont les donn�es sont des "char*".
Est-ce qu'avec les CRT, le probl�me peut venir de l�.

Je rappelle qu'en static, il n'y aucun plantage, alors qu'en Shared DLL, il y a plantage. Quelle autre diff�rence diff�rence majeure, a part que les fonctions MFC sont compil�es avec l'�xecutable en static, peut- il y avoir entre Shared DLL et static? au niveau des CRT justement,si diff�rence il y a ?

**farscape** · 10/07/2007, 16h02

est ce que ton programme utilise des .lib ?
si oui quelles sont les options de compilations de ces modules ?
tu dois avoir les m�mes que ton programme /MD (Multithreaded DLL) ou /MT (Multithreaded ) c'est �a qui change au niveau de la crt.

**Denn's** · 11/07/2007, 08h44

salut,

Non, en fait c'est juste un ex�cutable tout seul, rien de plus, pas la moindre *.dll ou *.lib.

**farscape** · 11/07/2007, 09h34

Alors si �a plante c'est que tu as un bug de debordement m�moire r�v�l� par le changement de contexte du programme (dll mfc ou static MFC).
ton probl�me vient certainement de ta gestion des listes chain�es.

**Denn's** · 13/07/2007, 09h07

Info suppl�mentaire:

Je builde en MFC shared DLL.
J'ex�cute et �a plante, je fais annuler pr d�boguer et j'ai les lignes en assembleur.
Je fais Shift + F5 pr arr�ter le d�bogage et dans la fen�tre o� j'ai habituellement, lorsque je builde, " O erreurs et 0 Warnings", j'ai des messages d'erreur concernant:
MFC42.dll
msvcrt.dll
kernell32.dll
.......
et plein d'autres fichier *.dll contenus ds C:\Winnt\System32
+
le msg :"L'application a termin� ac le code d'erreur 0."

Est-ce qu'il n'y a pas un flag au niveau des settings � rajouter pr qu'il trouve bien tous ses petits, comme il le fait en Static Library.
Quand on regarde la MSDN, il est indiqu� que 9 fois sur 10, le probl�me vient de zones m�moires non prot�g�es. En static, apparement, le compilateur s'en sort, pourquoi en DLL, il n'y arrive pas. Il y a un concept qui m'�chappe au niveau des DLL ?

Quel est le moyen quand on est en release, si il existe, de trouver le nom de la fonction qui fait planter ?

Merci d'avance pr les r�ponses que je pourrai recevoir.

**Denn's** · 06/08/2007, 12h50

Salut,

Effectivement Farscape, j'ai un souci au niveau Liste Chain�e.

Que je fasse un malloc( ) ou un new, je ne peux m�me pas tester le pointeur de retour pour v�rifier si il est NULL ou diff�rent de NULL, l'application plante au moment de l'appel � new/malloc ( En version Release - DLL MFC ).

En mode debug, en revanche, �a fonctionne toujours.

**farscape** · 06/08/2007, 12h58

je connais pas ta gestion de liste chain�e mais bon il existe des objets qui font d�j� le boulot dans les mfc et dans la stl (CList et list)
pourquoi ne pas utiliser ce qui existe d�j� voir l'adapter si n�cessaire ?

**Denn's** · 12/09/2007, 10h41

Salut,

C'est un fait.Pourquoi pas.
Mais �a ne m'explique pas pourquoi un malloc() ou un New me fait planter l'appli avant m�me que j'en teste le retour. Est-ce qu'il peut y avoir des probl�mes avec le Heap, je ne fais pas non plus de l'allocation � tire-la-rigot, il doit y avoir encore de la place au niveau de la m�moire. L'allocation se fait bien dans l'espace d'adressage du processus ? Est-ce qu 'il y a une limite � ne pas d�passer ? L'ex�cutable en lui m�me fait � peine 400 Ko.

Merci de vos r�ponses.

**farscape** · 13/09/2007, 06h56

sans voir le code et le type d'erreur, la seule chose que l'on peut dire c'est que tu dois avoir un bug li� a l'utilisation des pointeurs.

**stephdim** · 13/09/2007, 12h25

Le HEAP est corrompu --> tu dois ecrire, qque part dans ton code, en dehors des zones allou�es par un malloc / new.

Le HEAP est en gros une liste chain�e (je simplifie) avec un en-tete (header) devant chaque bloc allou� pour contenir les pointeurs de la liste chainee. Si tu �cris la dedans par erreur, �a fait ton probleme.

Maintenant en version DEBUG, le header de ces blocs est diff�rent, il y a plus d'infos pour le debug, �a se trouve tu �crases aussi une var de ce header, mais comme la structure est diff�rente, c'est peut etre une variable moins "vitale", c'est pour �a que �a fonctionne en DEBUG.

Bien verifier tes acc�s en �criture dans la m�moire.

@+

[MFC] Probl�me Release/Debug

MFC

Discussions similaires

Partager

Partager