Version imprimable
Salut,
j'ai une application Dialog - MFC qui fonctionne très bien en mode debug.
Dès que je passe en mode release, j'obtiens des messages d'erreur du type :
Je fais donc "Annuler" et je tombe sur :Citation:
Envoyé par Erreur d'application
Dans Visual C++ 6, où puis-je trouver ce qui correspond à cette adresse mémoire ? Cela correspond je pense à un écrasement mémoire. Comment le pister ?Citation:
Envoyé par Erreur d'application
merci
Dans les options de compilation, active la génération des symboles de débogage et recommence, il devrais te donner le nom de la fonction qui bug.
Voici les options que je viens de modifier :
Project Settings -> Win32 Release
[*]onglet Link
- onglet C\C++, Category General[list:ec64bce1ac]
- Optimizations : Disable (Debug)
- Debug info : Program Database for Edit and Continue
[/list:u:ec64bce1ac]
- Generate debug info : enabled
et je ne vois pas le nom de la fonction qui bug.
Où doit-il apparaitre ? dans l'IDE ou dans le message d'erreur ?
Juste ça ça suffit.Citation:
Envoyé par Aymerik
Lors du crash, fait annuler pour déboguer. Consulte la pile des appels, les adresses genre 0x73dd1c7 devraient avoir été remplacées par le nom des fonctions.
Lorsque je fais annuler pour déboguer, mon programme tourne encore tout en ayantdevant mon IDE. je bouge donc cette fenetre et j'arrete mon programme (break execution) et je ne trouve aucune de mes fonctions dans la pile :Citation:
Envoyé par Erreur d'application
---------------------------------------Code:
2
plus tard...
je viens de "trouver" l'erreur : en commentant un "UpdateData(false)", les erreurs ne se produisent que lors du survol de la souris sur ma fenetre. Je suppose que lors d'un survol souris, la fonction "DoDataExchange" est appelée ?
donc dans ce cas mon erreur se situe dans l'une des variables citées dans cette fonction. C'est bien cela ?
il n'y a pas d'appel a updateData sur le survol de la souris .
sauf si tu l'a implementé sur une fonction de deplacement de la souris...
met un AfxMessageBox("ligne xxx") dans on OninitDialog (si c'est une dialogue) avant / apres le premier UpdateData.
note: si c'st un pb de variables ça doit planter en debug.
:D
ok, c'est pas un problème de variables.
Le plantage intervient uniquement dans un certain cas : déclenchement d'un timer puis envoi d'un message puis execution d'une fonction.
Sans quoi je pratique le UpdateData régulièrement !
je vais continuer à investiguer :?
en collant des AfxMessageBox aux endroits strategiques tu peux approcher de l'erreur..
:D
:merci: pour les pistes, je continue...
si tu remontes la piles tu devrais en trouver.Citation:
Envoyé par Aymerik
Bonjour,
est ce que quelqu'un a trouvé la solution à ce pb? j'ai les mêmes "symptomes" dans mon code avec un setTimer(...). Ca marche très bien en mode debug mais pas en mode release. et dès que j'enlève le setTimer, le reste marche bien en mode release....
ce n'est relié à aucune instruction en particulier, le code a l'air d'être corrompu (des données effacées) de façon non définie: il suffit que je rajoute un bouton dans ma fenêtre avec un traitement de base (afficher des données sur une console) pour que j'ai l'erreur Access volation....
Je voulais savoir si klk'1 avait des idées/suggestions...
La solution radicale que j'ai trouvé est de re-prendre mon code en C et laisser tomber les MFC...;
ce n'est certainement pas la faute des MFC ..
la verité est ailleurs....
Ce n'est pas la faute à mon code en tout cas :))
Je n'ai pas trouvé mieux pour le résoudre et cela fait à peu prés 3semaines que ça me fatigue...
D'un autre côté, pour en avoir le coeur net, j'ai créé un nouveau projet avec le wizard de VC++ 6 (MFC AppWizard Exe ensuite Dialog Based ensuite Finish).
Je n'ai rien changé au code existant à part le rajout de:
+ SetTimer(1, 1000, NULL) dans le InitDialog de la fenetre,
+ Redirection du traitement de WM_TIMER à une de mes fonctions: ON_MESSAGE(WM_TIMER, MyOwnTimerProc())
+ Déclaration de la fonction (afx_msg void MyOwnTimerProc()...),
et c'est tout. et j'ai qd même pu créer l"Access Violation en mode release....
et bien c'est que tu te plantes mon cher ami .
crois tu etre le seul a avoir du utilisé un SetTimer ?
toujours se remettre en cause avant de dire c'est l'api ou la lib MFC qui ne fonctionne pas ...
:D
Je suis d'accord avec toi. par contre je ne sais pas où est ce que je fais l'erreur!!
et bien pour ça il nous faudrait voir le code...
ou un projet minimaliste qui reproduit le probleme, et que tu peux joindre au post.
:D
je suis nouveau sur le forum j'avais pas vu que ta réponse était sur une deuxième page :)
SInon pour créer le pb, il suffit d'ouvrir un nouveau projet sous VC++ 6 (MFC Appwizard exe), ensuite, DialogBased et puis finish. on appelle le projet testTimer par exemple.
Dans la fonction testTimerDlg::OnInitDialog(), on rajoute la ligne suivante:
unsigned int test_Timer = SetTimer(1, 2000, NULL);
ensuite on rajoute la ligne suivante:
ON_MESSAGE(WM_TIMER, myTestTimer)
entre le BEGIN_MESSAGE_MAP et le END_MESSAGE_MAP() du même fichier
et enfin on rajoute:
afx_msg void myTestTimer();
avant le DECLARE_MESSAGE_MAP() dans le fichier testTimerDlg.h
et voilà, tu as le pb en exécutant le code en mode release....
Tu penses bien que tu n'es pas le seul au monde à avoir utilisé un timer dans une application MFC et que si c'etait buggé ça se saurait ....
Si tu avais utilisé l'assistant de visual tu n'aurais pas eu de problémes , et ton code serait alors correcte.
voila un exemple de ce que génére visual sur le message WM_TIMER:
Toujours se remettre en question avant de dire c'est la lib qui ne fonctionne pas et mon code est correcte....;)Code:
2
3
4
5
6
7
8
9
10
11
12
13
merci pour la réponse, ça marche mnt..
sinon pour clore le sujet sur ma remarque précedente, c'était sarcastique...
En tt cas, c'est super. c'était un pb qui me prenait la tête depuis un moment et je n'avais pas pensé au class wizard...