Discussion :

[Denn's]

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]

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.

[farscape]

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]

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]

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]

Mais encore ?!

[Denn's]

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

[Denn's]

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]

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]

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]

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]

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.