Version imprimable
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
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 :aie:
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 :aie:
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à?
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 :cry:
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.
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.Citation:
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.
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.
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 )Citation:
Envoyé par Klaim
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.
Je ne pensais pas a un cas d'application threadé, mais ça reviens au même.Citation:
Envoyé par LittleWhite
Quand un programme Windows crashe sans AUCUN message d'erreur, ni même une fenêtre de rapport d'erreur (en supposant que celui-ci soit activé, et pour avoir les messages je déconseille de le désactiver), c'est souvent un débordement de pile (le programme n'arrive pas à lancer DrWatson quand le plantage vient de là).
Où règle-ton cette activation/désactivation.Citation:
Envoyé par Médinoc
Je pense aussi que c'est un problème de pile.
Il y deux manières de déborder la pile je pense:
-quand on fait des appels récursifs à l'excès, ou quand il y a trop d'appels de fonctions imbriquées;
-quand on a une variable de type tableau sur la pile et qu'on la déborde (genre char c[5]; c[10]=...).
Je doute fort que se soit le premier cas. Reste le deuxième cas qu'il faudra que je re-re- et re-regarde.
Pour reparler de la fonction Run(), la séquence des opérations sont indépendantes. En fait elle est du genreLes paramN étant simplement un test sur les paramètres passés à main() par le prg appelant (la ligne de commande). Et à propos, quel est la durée de vie de ces paramètres ? La même que celle du prg lui-même je suppose.Code:
2
3
4
5
Dans ce genre de situation (corruption mémoire imprévisible), c'est souvent Purify qui me sauve la mise. :mrgreen:
Dans les propriétés système, il doit y avoir quelque part une option rapports d'erreur.Citation:
Envoyé par camboui
Quand je suis affecté à une mission de type pompier, le coût de « ça plante qu'une fois sur mille », c'est un cas de figure très (trop) fréquent.
Comme je suis là en pompier, les règles de bonnes pratiques de codage, comme l'utilisation de vérificateur, ou d'outils comme Purify ou encore une simple lecture des warnings du compilateur n'ont pas été faites.
Résultats, si vous commencez à le faire après, vous êtes noyé sous des indicateurs calamiteux avec un client qui veut une application opérationnel et sûre pour hier.
Donc l'outil du pompier, c'est ADPlus
http://support.microsoft.com/kb/286350/fr
Pour faire simple, il permet de faire des dumps mémoire (.dmp) d'un processus, quand on veut, quand il plante, quand il d'arrête.
Avec le dump mémoire et les fichiers .pdb (générable même en Release) de votre programme, utilisez WinDbg (ou Visual Studio mais je crois que sa configuration pour lire les .dmp est assez complexe, du moins elle l'était).
Avec le débuggeur (WinDbg ou VS), vous pourrez voir la ligne exacte et la valeur des variables, la pile d'appel, toute la mémoire, etc...
Vous saurez qu'est-ce qui a merdé, il ne vous restera plus qu’à savoir pourquoi et comment.
P.S.:
Vous installez le monitoring du programme chez les utilisateurs (via un lien par exemple), comme ça, eux qui testent les 1/1000.
Bon ben merci pour tous les conseils prodigués, et désolé d'y revenir quelques mois plus tard :oops:
J'ai résolu le problème il y a 2 mois. Enfin, je considère qu'il est résolu car il ne s'est plus jamais manifesté depuis.
C'est donc bien une erreur de codage dans une classe de base vieille d'une dizaine d'années et utilisée un peu partout (raison pour laquelle le plantage survenait dans de multiples contextes). Elle utilise un buffer de taille N mais dans quelques cas une fonction membre accède au N+1ème caractère :aie:
Vieux comme il est, je m'étonne que cette erreur ne se manifeste que maintenant, mais à l'époque le buffer faisait 4000 octets. Puis je l'ai changé en 4096, allez savoir pourquoi :roll: