[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