Version imprimable
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 ?
8O
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.
ça n'a pas l'air d'inspirer grand monde.....:?
c''est déjà une piste a étudier.Citation:
Envoyé par syn42
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...
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 ?
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).
Mais encore ?!
8O
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 ?
:?
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.
Salut,
A quoi puis-je voir que j'utilise pls CRT différents ?
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 ?
:roll:
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.
salut,
Non, en fait c'est juste un exécutable tout seul, rien de plus, pas la moindre *.dll ou *.lib.
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.
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.
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.
:evilred:
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 ?
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.:(
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.
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.
@+
Salut,
J'ai fait d'autres tests et plus simples pour cerner le problème.
J'en arrive au fait que même les 2 lignes suivantes dans le corps d'une méthode font planter l'appli:
Je ne peux même pas tester le retour de p.Code:
2
3
Le msg d'erreur me dit que l'instruction à l'adresse x ne peut pas écrire dans la zone mémoire à l'adresse 0x00000000000000.
C'est une classe que j'ai importé d'un autre projet ( développé avec MingW Developper Studio ), que je n'ai pas crée avec VC++. J'ai juste fait "Ajouter un *.h et *.cpp" dans mon projet, rien de plus. Est-ce que ça peut venir de là ?
ça ne veut rien dire tout ça ...
qui me dit que l'objet qui appel cette méthode n'est pas null ou foireux ?, que l'environnement avant cet appel n'est pas déjà corrompu?
une ligne de code peut être correcte, mais si le contexte d'appel est pourri ça
plantera.
Il est quand même préférable en C++ d'utiliser new à la place de malloc..
Le malloc à la place du New, c'était pour illustrer..
L'objet lui,est correct puisqu'avant de lui faire allouer la mémoire,
je lui fais afficher une MessageBox().
En Release/Static Library, je rappelle que ça fonctionne.
Depuis le début de la discussion, la question devient en fait:
Est-ce qu'il y a une différence de la gestion mémoire entre la Static Library et la Shared DLL au niveau Release, et si oui, comment lui faire faire en Shared DLL ce qu'il arrive à faire en Static Library, avec des options de link ou de préprocesseur, que sais-je encore ?
Voilà.
je t'ai déjà répondu à ce sujet , la réponse est non cela fonctionne de la même manière .
un probléme peut survenir dans le cas que j'ai cité:
Citation:
Envoyé par farscape
Salut,
Comment puis-je savoir que j'utilise différentes versions de CRT ?
Qu'est ce qui a pu faire que j'utilise des versions différentes de cette sans l'avoir voulu explicitement ?
Comment y remédier, est-ce que c'est dans "Project/settings" que ça se paramètre ?
Est-ce que c'est un *.lib qui se met dans le répertoire des sources au moment du "Build" ?