Discussion :

[kacedda]

Bonjour,

Lorsque je code; j'ai plus ou moins trois mode:
debug
release + trace (pour debugger la release )
release (pour clients - la plus legere possible)

Du coup dans le code (qui n'est pas tout de moi), je me trouve parfois avec:
methode 1

Code :

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

1
2
3
4
 
#ifdef __TRACE
affiche( "Message pour debugger" )
#endif

methode 2

Code :

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

1
2
3
4
5
6
7
8
9
 
#ifdef __TRACE
#define affiche( x )  affiche(x)
#else
#define affiche( x )
#endif
 
// et dans le code
affiche ( "Message pour debugger" )

methode 3

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class trace{
#ifdef __TRACE
  inline affiche(x) {affiche(x); };
#else
  inline affiche(x) { };
#endif
}
 
// Et dans mon code
pTrace->affiche( "Message pour debugger" );

Je trouve les deux premières methodes lourdes et je prefere la 3eme.
Mais je me demandai, ma fonction affiche() utilise plus de parametre que dans l'exemple, du coup meme si je compile en release sans __TRACE, est-ce que la pile de paramètre ne va pas être intégré dans le code final?
Le simple fait d'utiliser mon pointeur et de faire appel va generer du code, n'est-il pas?

Enfin sinon comment faites vous vous ?

Merci

[Pragmateek]

Ce type d'opérations ne serait-il pas mieux géré par des loggers comme log4cxx : http://logging.apache.org/log4cxx/index.html ?

Ce type d'outils permet de diriger les flux de messages aisément, ou de ne pas les logger du tout en release par exemple.

[jabbounet]

je suis plus du genre a utiliser un debugger quand il y'a un souci

les traces que je laisse sont des traces applicatives (via un loggeur ou autre),

Jamais des traces de debug que je nettois systématiquement un fois le problème corrigé.

[kacedda]

Ce type d'opérations ne serait-il pas mieux géré par des loggers comme log4cxx

+1 (mais quand c'est pas fait des le debut...)

je suis plus du genre a utiliser un debugger quand il y'a un souci

ok et quand:
- environnement multi-thread, le fait de se mettre en debug bloque le thread ce qui bloque les autres thread...
- bug qui ne se produit que dans certaines conditions, une fois tout les mille ans...
- bug qui se produit que chez un client, et que sur sa machine (a cause d'un driver video completement foireux (j'ai eu!!)) et je me vois mal installé un debugger chez le client!
- ...

[jabbounet]

- environnement multi-thread, le fait de se mettre en debug bloque le thread ce qui bloque les autres thread...

tu peux utiliser un debugger en multithread tu peux chopper ton appli au vol avec son pid, tu peux lui demmander de s'arreter quand elle rentre dans une methode particulière (apres si les autres threads continue leur vie et se crash pendant que tu debug ta methode c'est pas le souci tu te focalise sur la methode qui plante)

bug qui ne se produit que dans certaines conditions, une fois tout les mille ans...

si tu connais les conditions tu sais le reproduire

bug qui se produit que chez un client, et que sur sa machine (a cause d'un driver video completement foireux (j'ai eu!!)) et je me vois mal installé un debugger chez le client!

Si te traces applicatives sont suffisament bien faite tu sais par quel chemin est passé ton client pour produire le bug.

[kacedda]

[quote=jabounet]Si tes traces applicatives sont suffisamment bien faite tu sais par quel chemin est passé ton client pour produire le bug.[/trace]
ok, je viens de comprendre un truc => trace applicative = trace tout le temps
C'est ce genre de chose qu'on fait pas.
En fait, dans nos appli on ne met les traces qu'en cas d'anomalie et on se retrouve sans le cheminement!

[jabbounet]

Si tes traces applicatives sont suffisamment bien faite tu sais par quel chemin est passé ton client pour produire le bug.

ok, je viens de comprendre un truc => trace applicative = trace tout le temps
C'est ce genre de chose qu'on fait pas.
En fait, dans nos appli on ne met les traces qu'en cas d'anomalie et on se retrouve sans le cheminement!

Non, on ne trace pas tout, tout le temps. C'est trop couteux en terme de perfs.
tu as des niveaux de trace qui peuvent faire que ton appli est plus ou moins bavarde (INFO, WARNING, ERROR, FATAL, LOG), ce qui est tracé tout le temps ce sont les LOG et les FATAL, les autres peuvent être desactivés.

Et quand ton client detecte un souci et que tu n'arrive pas a reproduire tu lui demande de relever temporairement sont niveau de traces.
mais ce ne sont pas des traces de debug dans le sens ou elles respect un format bien précis et que ce n'est pas des printf("coucou je suis passé par là");

[kacedda]

(INFO, WARNING, ERROR, FATAL, LOG)

En fait j'ai dit une bêtise, on a bien un fonctionnement similaire, j'étais a l'ouest!
C'est juste que des fois, j'aimerais bien tout tracer jusqu'au contenu des variables, mais la ça devient trop lourd niveau code, d'où le coup de ne l'afficher que dans certains cas.
Mais bon je me rend compte en causant que mon principe de mettre des #ifdef __TRACE correspond juste a un level de plus finalement.

ok ça m'a bien éclairci la tête!

PS:

Citation:
bug qui ne se produit que dans certaines conditions, une fois tout les mille ans...
si tu connais les conditions tu sais le reproduire

Je pensai a des conditions encore inconnues

[jabbounet]

Ceci dit il faut faire attention aux perf quand tu utilise un traceur car le passage de paramètres a un prix

pour le cas java (choppé vite fait sur le net)

Code :

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

1
2
3
4
5
 
if(logger.isDebugEnabled() {
   logger.debug("Entry number: " + i + " is " +
   String.valueOf(entry[i]));
}

est mieux que

Code :

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

1
2
3
 
logger.debug("Entry number: " + i + " is " +
String.valueOf(entry[i]));

car dans le second cas même si le log debug n'est pas actif la chaine passé en paramètre est quand même évalué (ce qui peux couter cher).

[jabbounet]

Mais bon je me rend compte en causant que mon principe de mettre des #ifdef __TRACE correspond juste a un level de plus finalement.

pas tout à fait fait car cela dépendra de la façon dont tu génère le binaire et non d'un paramètre de configuration de ton application/traceur

[ram-0000]

Comme ce problème est récurent, je me suis créé une petite bibliothèque de gestion des traces WinLog que j'utilise pour tous mes projets.

Un seul problème (si c'est vraiment un problème ?), c'est orienté développement Microsoft

[mister3957]

Et est-ce que vous typez vos messages de log ? Info, warning, error ?

Perso je propose une interface de log, qu'implémenterons différents logger (un vers un fichier, un vers la partie debug du compilateur etc.) permettant pour l'utilisateur de ce système, de pouvoir implémenter son propre logger afin d'afficher les messages dans une partie de son IHM par exemple, où enregistrer les erreurs en base, les envoyer sur un socket etc...

Puis un point d'entrée, à qui on envoi les messages et dont le rôle est de les transmettre aux différents loggers "branchés".

Cela permet, qu'en cours de développement, d'avoir continuellement les messages sous les yeux, sans devoir sans cesse checker les fichiers.

Pour l'utilisation, je rajoute des opérateurs de flux, afin de ne pas laisser l'utilisateur du gestionnaire de log faire les conversions en chaînes.

[nicroman]

Par experience, c'est toujours en release chez le client qu'on a besoin des traces

Donc pas de #ifdef pour "virer" le code de logging
Mais un vrai logging (j'aime pas trop log4cxx qui essaye de reproduire un log4j antédiluvient). On a une librairie interne pour ça, qui utilise un 'contexte' de thread pour savoir ou les choses doivent être loguées et quoi doit être logué au minimum, et des settings (à la log4xxxx) pour savoir quoi doit être logué par défaut. Tout est modifiable dynamiquement (par exemple "hooker" le debugguer microsoft rajoutera dynamiquement une sortie vers la fenetre de debug).

Notre systeme combine donc:
- Des "LogOutput" (file, e-mail, thread-history, debug-window)
- Un contexte de thread (qui determine les LogOutput, leur niveau de log, et le niveau minimal de logging)
- Un logger par 'module' (classe, module logique, ...) qui determine le niveau minimal de logging.
- Les fonctions log vont utiliser le logger du module & le contexte, si le niveau dépasse l'un des deux, le log sera fait a travers les contexte.
- Les levels suivants: "Trace", "Debug" (chemins d'executions), "Warning" (erreurs récupérables), "Info" (opérations atomiques), "Error" (erreurs inattendues nécessitant l'arret de l'opération en cours), "Fatal" (erreurs inattendues et mettant en péril l'application).

Chez le client, on est par défaut en mode "info" (info, error, fatal sont les seuls 'levels' logués, parmi: trace, debug, warning, info, error) mais on peut passer des modules en mode debug, ou alors, des contextes entiers.... Même avec la release.
Sans compter le systeme qui nous envoit un e-mail directement a chaque "fatal" avec un appercu des X derniers logs effectués par le thread.
L'overhead est très faible, et la facilité d'analyse des bugs... accrue