Discussion :

[camboui]

J'ai un prg qui plante 1 fois sur 100 (ou sur 1000). Pas souvent donc, mais c'est quand même trop.
Le problème est qu'il plante sans qu'aucune exception ne soit interceptée malgré un catch(...) dans le main. Windows se débarrase du prg comme un malpropre (avec un errorlevel mais je ne sais pas lequel).

Je soupçonne le stack corrompu par un écrasement occasionnel.
D'autres idées ?
Et comment y rémédier ?
Merci

[koala01]

Salut,

A défaut d'autres informations, je te proposerais bien de jeter le programme toi aussi, mais je crains que cela ne fasse pas ton affaire

Plus sérieusement, ce peut être une corruption de la pile ou un quelconque signal d'erreur similaire.

Si c'est un programme que tu t'es procuré ailleurs, fait une remontée de bug (si possible).

Si c'est un programme à toi, essaye de vérifier correctement ton code, voire, d'essayer de cerner plus précisément le problème, mais, s'il ne plante que de manière aléatoire (toutes les X ou Y exécutions), il faudrait déjà essayer de comprendre dans quelles circonstance ce plantage survient, histoire de pouvoir te mettre dans une situation où il surviendra systématiquement et avoir une chance d'en trouver la raison

[Klaim]

Tu peux utiliser un debugger type visual studio non? Que te dis ton debugger exactement quand ça plante?
Ou alors ça se passe avant même l'execution du main() ? Si c'est le cas, c'est très certainement que tu as quelque chose de trop gros dans ta stack, peut être un tableau énorme ou quelque chose dans ce gout là?

[camboui]

Je vais essayer d'être plus précis: ça ne plante qu'en release et très rarement. J'ai jamais réussi à le faire planter en debug.

Le workaround pour l'instant est simplement de le relancer quand il s'est planté. Comme je le disais il ne plante que très rarement.
Ainsi, si je lance le programme des dizaines de fois à la suite les unes des autres, avec exactement le même contexte (données, paramètres, etc), il ne plantera qu'une fois de temps en temps.
Curieux, et très emm...ant

Ceci dit, je sais dans quelle fonction il plante. Il y a la fonction main() (c'est un prg en mode console) puis une fonction Run() appellée par main(). Dans cette fonction Run() j'exécute un ensemble de tâches séquentiellement. C'est lors de la fin d'une de ces tâches quelconques que le programme s'arrête. C'est donc toujours dans Run() que ça plante.
A vos idées, merci.

[Klaim]

Je vais essayer d'être plus précis: ça ne plante qu'en release et très rarement. J'ai jamais réussi à le faire planter en debug.

Ce cas est commun et souvent c'est qu'une de tes variable membre n'a pas d'initialization définie dans le constructeur de classe.
Je te conseil de faire le tour de tes classes et de vérifier voir si il manque pas une initialization quelque part.


Sinon, dans Run j'imagine que les taches sont dynamiquement gérées et donc ça n'a rien de déterministe? Il se peut que ton problème arrive a un moment ou la liste des taches est changée non? Tu devrais ajouter un log pour vérifier ça, en affichant quand tu la change et quels taches (nommées du coup) sont ajoutées/enlevées.

[LittleWhite]

Sinon, dans Run j'imagine que les taches sont dynamiquement gérées et donc ça n'a rien de déterministe? Il se peut que ton problème arrive a un moment ou la liste des taches est changée non? Tu devrais ajouter un log pour vérifier ça, en affichant quand tu la change et quels taches (nommées du coup) sont ajoutées/enlevées.

J'ai pensé, moi aussi en lisant cette histoire de Run(), que ça pouvait être un problème de priorité ( race bug ? ). Soit une fonction qui doit attendre une autre mais qui est executé avant la fin de celle ci. ( Mais je croyais que ça arrivait que dans les programmes threader )

[jabbounet]

je ne connais pas tres bien le process de compîl sous studio,

il n'y pas possibilité d'activer les Warning de compil (ça ne fait pas tout) d'insérer des traces, d'utiliser des outils de vérification type valgrind/ ...


autrement une autre piste peu consister à essayer d'identifier le use-case qui fait planter en sauvegardant des contextes de ton appli (états des variables, données d'entrées, ...) à des points stratégiques et t'arranger pour pouvoir les rejouer quand tu identifie un jeu de données qui fait planter.