Discussion :

[Aymerik]

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 :

L'instruction à "0x73dd1c7" emploie l'adresse mémoire "0x000013b". La mémoire ne peut pas être "read".

Cliquez sur OK pour terminer le programme.
Cliquez sur Annuler pour déboguer le programme

Je fais donc "Annuler" et je tombe sur :

L'instruction à "0x73dd1c7" emploie l'adresse mémoire "0x000013b". La mémoire ne peut pas être "read".

Cliquez sur OK pour terminer le programme.

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 ?

merci

[Aurelien.Regat-Barrel]

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.

[Aymerik]

Voici les options que je viens de modifier :

Project Settings -> Win32 Release

• onglet C\C++, Category General[list:ec64bce1ac]
• Optimizations : Disable (Debug)
• Debug info : Program Database for Edit and Continue

[*]onglet Link

• Generate debug info : enabled

[/list:u:ec64bce1ac]
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 ?

[Aurelien.Regat-Barrel]

• onglet Link[list:3a6a087b93]
• Generate debug info : enabled

[/list:u:3a6a087b93]

Juste ça ça suffit.

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.

[Aymerik]

Lorsque je fais annuler pour déboguer, mon programme tourne encore tout en ayant

L'instruction à "0x73dd1c7" emploie l'adresse mémoire "0x000013b". La mémoire ne peut pas être "read".

Cliquez sur OK pour terminer le programme.

devant 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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
NTDLL! ...
KERNEL32! ...

---------------------------------------
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 ?

[farscape]

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.

[Aymerik]

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

[farscape]

en collant des AfxMessageBox aux endroits strategiques tu peux approcher de l'erreur..

[Aymerik]

pour les pistes, je continue...

[Aurelien.Regat-Barrel]

je ne trouve aucune de mes fonctions dans la pile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
NTDLL! ...
KERNEL32! ...

si tu remontes la piles tu devrais en trouver.

[Hassanine2005]

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...;

[farscape]

ce n'est certainement pas la faute des MFC ..
la verité est ailleurs....

[Hassanine2005]

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....

[farscape]

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 ...