Discussion :

[SERTNM]

Hello,
Voilà mon souci : je développe une application MFC dialog based. La boite de dialogue me sert d'interface. J'ai ajouté un thread pour tout ce qui est calcul, analyse...etc. Ce thread démarre et s'arrête avec l'application. Il s'agit d'un CWinThread démarré par AfxBeginThread().

Quand j'exécute mon programme compilé en Debug ou en Release celui ci plante au bout de quelques heures : apparement le thread d'analyse ne tourne plus (bien qu'il existe encore).

En revanche quand j'exécute mon programme à partir de la commande Go de visual celui-ci tourne sans problème des jours et des jours... le bug a disparu !!!

d'ou ma question : quelles différences y a t il entre une exécution classique du fichier exe compilé en debug et une exécution "Go". Est ce que visual réserve des zone mémoires plus grandes ou ce genre de trucs ?

J'ai lu ici ou là qu'avec les MFC le multithreading n'était pas très sûr (fuite mémoire...etc.) Est ce que mon plantage pourrait être lié à çà ?

Merci

[farscape]

salut,
tu fais fausse route,
si ton programme plante en release ,c'est qu'il y a un bug et c'est souvent un débordement mémoire qui en est la cause.
et quelque soit le mode de lancement du programme .
si ton programme plante aussi en debug le problème devrait être facile à résoudre.
il suffit sur la ligne d'erreur de remonter la pile des appels jusqu'au ton code et regarder la ligne qui cause un problème.
ps: travailler avec un thread en MFC impose des contraintes :
http://c.developpez.com/faq/vc/?page...d#WorkerThread
avec un boite de dialogue il vaudra mieux utiliser PostMessage.

[Médinoc]

Son problème n'est pas "ça plante en release".
Si tu relis son post, tu verras que le problème est "ça plante en debug comme en release hors du debugger, et le bug n'est pas reproductible dans le debugger"...

[SERTNM]

Mon thread est créé dans les règles de l'art (je m'étais appuyé en parti sur cette FAQ au début du développement) : des variables globales pour la communication boite de dialogue --> thread et PostMessage dans l'autre sens

Et effectivement Médinoc a bien cerné le problème. Je plante de la même manière avec une compil release ou debug.... sauf dans le debbuger, ce qui ne me permet pas d'avoir accès à la pile des appels... ce serait trop facil sinon !!!

[farscape]

hé bien tu es dans le cas le plus difficile à resoudre ...
quel est le message que tu obtiens quand ça plante ?
tu as surveillé les ressources (memoire ,objet gdi etc) quand tu executes ton programme ? (avec le gestionnaire de taches)

[SERTNM]

Quand çà plante j'ai le comportement suivant : l'application semble figée. Le thread est "mort" : bien qu'il existe encore il ne fait plus rien, comme bloqué. Du coup plus aucun résultat n'est mis à jour, plus aucune courbe s'affiche...etc. En revanche la boite de dialogue "vie" toujours correctement : si j'appuie sur un bouton qui n'a aucune interaction avec le thread (ex:affichage d'une autre boite de dialogue...etc.) tout ce passe bien.

Et pour facilité les choses le plantage arrive aléatoirement dans le temps (au bout de quelques heures ou de quelques jours) sans prévenir, pas de message d'erreur, rien !

Coté ressource avec le task manager je n'est pas de fuite de mémoire (physique ou virtuelle). Pas d'envolé non plus du nombre de handle ou de trucs comme çà.

[farscape]

tu as des attentes dans ton thread (Attente d'un évenement signalé etc) ?

[SERTNM]

Oui j'ai des mutex pour proteger divers éléments mais j'ai vérifié avec WINOBJ que lorsque je plante je ne suis pas dans un deadlock

[farscape]

tes mutex ils sont avec des attentes infinies ?

[SERTNM]

oui
un mutex avec une attente infinie peu poser d'autres problèmes que le Deadlock ?

[farscape]

si il n'est pas relâché tu peux avoir le problème que tu décris : le thread bloqué
...

[la drogue c'est mal]

meme avec ctrl+F5 en debug, si il y a un crash, tu peux aller à la ligne ou cela à planter. Apres il faut aller dans le bon thread

[SERTNM]

meme avec ctrl+F5 en debug, si il y a un crash, tu peux aller à la ligne ou cela à planter. Apres il faut aller dans le bon thread

A tient je savais pas çà...
Je vais essayer tout çà et peut-être découvrir le bug mystère !!!

[SERTNM]

meme avec ctrl+F5 en debug, si il y a un crash, tu peux aller à la ligne ou cela à planter. Apres il faut aller dans le bon thread

Bon, de retour de déplacement professionnel, je me remet dans mon problème... En fait je vois ce que tu veux dire : si tu plantes et qu'une boite de dialogue apparait tu peux cliquer sur "Debuggage" et retourner dans ton code. Le problème c'est que quand je plante rien ne se passe, mon thread s'arrete sans hurler, sans exeption, pas même une petite boite de dialogue !!! NADA !

[Médinoc]

Une erreur système parfaitement silencieuse sous Windows, c'est généralement un débordement de pile.
Si c'est silencieux SANS erreur système, c'est qu'il y a dans ton code une instruction qui ordonne au thread de se terminer, et que cette instruction est appelée à un moment où elle n'était pas censée l'être.