Comment affichez vous vos trace pour debugger?

Version imprimable

22/07/2009, 14h47
kacedda

Comment affichez vous vos trace pour debugger?
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:

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

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:

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 ? :D

Merci
22/07/2009, 14h54
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.
22/07/2009, 15h07
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é.
22/07/2009, 15h47
kacedda

Citation:

Envoyé par seriousme

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...:aie:)

Citation:

Envoyé par jabbounet

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 :cry: (j'ai eu!!)) et je me vois mal installé un debugger chez le client!
- ...
22/07/2009, 15h53
jabbounet

Citation:

- 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)

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 :ccool:

Citation:

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.
22/07/2009, 16h10
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!
22/07/2009, 16h29
jabbounet

Citation:

Citation:

Envoyé par jabounet

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à");
22/07/2009, 16h52
kacedda

Citation:

(INFO, WARNING, ERROR, FATAL, LOG)

En fait j'ai dit une bêtise, on a bien un fonctionnement similaire, j'étais a l'ouest:aie:!
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!:ccool:

PS:

Citation:

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 ;)
22/07/2009, 17h00
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:

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

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).
22/07/2009, 17h02
jabbounet

Citation:

Envoyé par kacedda

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
23/07/2009, 10h54
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
23/07/2009, 12h03
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.
23/07/2009, 17h03
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 :)