Discussion :

[magellan94]

Bonjour à tous!

Alors là, attention, problème plus d'analyse que de développement "pur"! Experts, idées (même saugrenues)... n'hésitez pas.

En gros:
Le problème
Une application développée en C# winform se "fige" en cours d'usage, mais ceci de manière totalement aléatoire. d'un poste à un autre, le blocage peut survenir après une journée d'utilisation, ou bien au bout de seulement une dizaine de minutes.

De fait: en tests unitaires, aucun souci. En tests plus intenses, aucun figeage constaté sur les plateaux. Mais... à l'usage réel, avec de nombreuses applis tierces ouvertes... ça se fige. Pire: le figeage est relativement "propre", car on peut basculer sur la fenêtre du client, le processeur n'est pas sollicité outre mesure, et la mémoire n'est pas non plus saturée.

Les infos concernant le programme
Threadé, appelant des Dll externes (pour préciser, c'est de la téléphonie), le pogramme appelle une base de données, et donc des DLL tierces. Mes soupçons se portaient sur les dites dll, mais visiblement je n'ai rien trouvé de signifiant à l'usage, d'autant plus que les cas de figeages applicatifs ne se produisent pas spécifiquement en cours de communication (ce qui induit que les dites dll ne sont pas en cours d'utilisation).

Mes questions
après avoir collé des logs à la pelle (sans succès), je n'identifie toujours pas le processus/thread qui pourrait provoquer ce souci.
Alors:
- Quels outils conseillez vous pour traquer le blocage?
- Comme le mode débug n'est pas l'idéal pour procéder à des tests d'endurance, vers quoi dois-je me tourner?

Pas facile, hein?

Tous les conseils sont les bienvenus!

[Graffito]

Pour commencer, je créerai dans l'application une forme annexe avec un simple bouton qui affiche un message "hello" et je la lancerai au début de l'application avec un show (non modal).

Cela permettrait de savoir si l'appli s'est totalement crashée.

Si la forme annexe continue à tourner (le bouton affiche "hello"), on pourra l'utiliser pour tracer les derniers appels et retours des fonctions appelant les DLL et identifier la fonction responsable du plantage.

Une fois la fonction identifiée, on pourra spécifiquement encadrer les appels aux DLL.

[Pol63]

il y a des profilers pour voir tout ce qui se passe dans l'appli, mais c'est pas forcément simple à utiliser

sinon avec system.diagnostics.stopwatch tu peux chronométrer l'exécution de morceaux de code, et donc voir lesquels prennent du temps et sont possiblement la source du freeze

seul le thread principal peut faire freezer l'appli, les thread secondaires ne sont pas utilisé pour le rafraichissement de l'interface

une connexion à une base de données peut etre longue sur des grosses requetes, ou des requetes qui retournent beaucoup de données
dans ces cas là, il faut les mettre sur un thread secondaire
sur sql server, il y a sql server profiler qui permet de voir les requetes qui sont longues à exécuter (pour voir celles qui retournent beaucoup de données c'est faisable aussi mais moins simple)

[magellan94]

Merci pour ces réponses.

globalement:
- Les requêtes BDD sont vraiment très simples (de simples SELECT à des tables minuscules. On ne contrôle que quelques données, rien qui nécessite de la gestion particulière). Je ne cible pas spécifiquement ce bout (quoique... vu le problème) mais la piste de profiler la connexion est une bonne idée.
- Savoir que c'est le thread principal qui peut figer est intéressant, mais il y a un "truc" qui m'horripile dans la façon dont cela a été développé. Je vais schématiser pour être "clair". En gros, imaginez une barre d'outils où c'est supposé être que des boutons.... où, en fait, c'est un tableau d'images clickables. Pourquoi s'être pris la tête avec ça? Bonne question, je récupère le code tel quel. J'ignore si, par hasard, ce n'est pas la gestion de ce ruban qui pose souci.

J'ai profilé le programme comme suit:
- Créé un programme annexe présentant un "serveur" sur un port donné
- Emis à chaque E/S de thread/boucles vers ce serveur pour le prog principal
Le tout pour avoir comme du "log", mais sans pour autant provoquer d'écriture par wagons entiers.
Résultat? Les figeages ne semblent pas se produire durant les boucles, car l'appli est comme "au repos" (pas de passage dans les boucles d'analyse de situation).

Au-delà: je soupçonne un thread ou une méthode dont une exception est mal gérée, et qui retourne une réponse absurde à un "while" (par exemple). Le while attendant un "true pour sortir, alors que la méthode appelée ne retourne que "false" (suite à une anomalie), la dite boucle ne sort plus, ceci laissant l'appli figée (esthétiquement), ne réagit plus à toute action de clic sur l'interface et ainsi de suite. De plus, je crains que le dit "while" soit dans le thread principal, d'où la difficulté à pister le blocage.

Là, j'ai lancé le programme pour le week end avec un "écouteur" logiciel qui est capable de détecter les exceptions .NET non traitées; Si en revenant lundi matin au boulot, le dit compteur a grimpé, et que le programme est figé, alors j'aurai, je pense, mis le doigt sur le souci potentiel.

Cependant, merci pour ces renseignements, et le coup de l'ihm m'intéresse. Je vais tenter cette astuce pour voir si c'est bel et bien le logiciel qui se vautre, ou s'il y a un composant tiers de bancal.

[Graffito]

je soupçonne un thread ou une méthode dont une exception est mal gérée, et qui retourne une réponse absurde à un "while" (par exemple). Le while attendant un "true pour sortir, alors que la méthode appelée ne retourne que "false" (suite à une anomalie), la dite boucle ne sort plus, ceci laissant l'appli figée (esthétiquement),

Lorsque ça plante, on peut voir en lançant le gestionnaire de tâche (CTRL-ALT-SUPPR) le pourcentage des ressources CPU utilisée dans la colonne processeur de l'onglet processus. Ce qui donnera une indications sur l'hypothèse de boucle sans fin.

[Pol63]

le pourcentage des ressources CPU utilisée dans la colonne processeur de l'onglet processus. Ce qui donnera une indications sur l'hypothèse de boucle sans fin.

un peu raccourci
un while true avec un thread.sleep(5) dedans et ca ne dépassera pas forcément 20% tout en étant infini

[StringBuilder]

- Les requêtes BDD sont vraiment très simples (de simples SELECT à des tables minuscules. On ne contrôle que quelques données, rien qui nécessite de la gestion particulière). Je ne cible pas spécifiquement ce bout (quoique... vu le problème) mais la piste de profiler la connexion est une bonne idée.

Vérifie quand même si t'as pas un DEADLOCK dans la base

Au-delà: je soupçonne un thread ou une méthode dont une exception est mal gérée, et qui retourne une réponse absurde à un "while" (par exemple). Le while attendant un "true pour sortir, alors que la méthode appelée ne retourne que "false" (suite à une anomalie), la dite boucle ne sort plus, ceci laissant l'appli figée (esthétiquement), ne réagit plus à toute action de clic sur l'interface et ainsi de suite. De plus, je crains que le dit "while" soit dans le thread principal, d'où la difficulté à pister le blocage.

C'est une bonne piste en effet.
Dans tes while (true), tu devrais ajouter un contrôle du temps d'exécution afin de déclencher un timeout : une DLL externe doit retourner n'importe quoi, ou alors figer. Et ton appli attendant une réponse indéfiniment, elle fige à son tour.

Du coup, je ferais un truc du genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
Datetime t1 = DateTime.Now;
 
while (true)
{
     // Ton traitement
     if ((DateTime.Now - t1).TotalSecondes > 30)
     {
          throw new Eception("Youpi tralala j'ai trouvé mon freeze");
     }
}

[Pol63]

le mieux si tu peux reproduire ca depuis visual studio est qu'au moment du freeze tu clic sur pause, tu verras où en est chaque thread ...

Vérifie quand même si t'as pas un DEADLOCK dans la base

en cas de deadlock une exception est déclenchée sur le thread détruit, donc il l'aurait vu passer en erreur